Here’s my solution. It’s pretty short.
Mitchell Koch
On 8/30/06, James Edward G. II [email protected] wrote:
On Aug 30, 2006, at 3:48 PM, Morton G. wrote:
I guess I need to read up on the philosophy behind unit testing.
Know any good references?You know, I’ve read a couple of books on the subject now and still
have not found one I just fell in love with. Hopefully others will
chime in with some good suggestions.
Well, I understand that test/unit is patterned after JUnit, which in
turn came from SUnit, one idea would be to google for terms like
junit
sunit
and
test infected
which is kind of a cult term.
I guess one of my claims to fame was that I was there when Kent Beck
“test infected” Erich Gamma, which led to JUnit.
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
On Aug 30, 2006, at 5:03 PM, James Edward G. II wrote:
is the same on my box. Sorry to spread confusion.
Just to make sure I looked at the implementation. It does call sort
on the test method names to establish the order for running the test.
I can’t imagine why it does this. If I were implementing something
like Test::Unit, as an application of principle of least surprise, I
would want to ensure Test::Unit preserved the order in which the
programmer defined the tests. That doesn’t mean I’m saying Nathaniel
Talbott has erred; he may well have a good reason that simply escapes
me.
Another thing I gleaned from the code was that it rejects any method
with arity other than 0 or -1; i.e, any method that can’t be called
with send(test_name), where test_name matches /^test./. I don’t
think this is mentioned in the Pickaxe book and it certainly isn’t
mentioned in the ri documentation, but it explains something else
that was niggling me: why Test::Unit was smart enough not to run my
test_arg_helper method as a test method.
Regards, Morton
On 8/30/06, Morton G. [email protected] wrote:
Just to make sure I looked at the implementation. It does call sort
on the test method names to establish the order for running the test.
I can’t imagine why it does this. If I were implementing something
like Test::Unit, as an application of principle of least surprise, I
would want to ensure Test::Unit preserved the order in which the
programmer defined the tests. That doesn’t mean I’m saying Nathaniel
Talbott has erred; he may well have a good reason that simply escapes
me.
Well, for one thing, I don’t believe that it KNOWS the order in which
the methods are defined.
Second, the unit tests really should be order independent. It
shouldn’t matter which order they run in. If you need to sequence code
it should be in the test methods.
I think of a test case as a bucket of tests, not any kind of ordered
collection.
–
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
On Aug 30, 2006, at 6:16 PM, Morton G. wrote:
If I were implementing something like Test::Unit, as an application
of principle of least surprise, I would want to ensure Test::Unit
preserved the order in which the programmer defined the tests.
An object’s methods don’t have an order.
irb(main):001:0> class X; def y; end; end
=> nil
irb(main):002:0> X.instance_methods(false)
=> [“y”]
irb(main):003:0> class X; def z; end; end
=> nil
irb(main):004:0> X.instance_methods(false)
=> [“z”, “y”]
irb(main):005:0> class X; def b; end; end
=> nil
irb(main):006:0> X.instance_methods(false)
=> [“z”, “y”, “b”]
–
Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
Eric H. [email protected] writes:
On Aug 30, 2006, at 6:16 PM, Morton G. wrote:
If I were implementing something like Test::Unit, as an application
of principle of least surprise, I would want to ensure Test::Unit
preserved the order in which the programmer defined the tests.An object’s methods don’t have an order.
Although I agree with the principle that unit tests shouldn’t depend
on the order they’re executed in (I actually think that Test::Unit
should sort the methods randomly to enforce this), the order that
methods are defined can actually be recorded in Ruby:
irb(main):001:0> class Foo
irb(main):002:1> def Foo.method_added(r); @meth ||= []; @meth << r;
end
irb(main):003:1> def Foo.get_meths; @meth; end
irb(main):004:1> end
=> nil
irb(main):005:0>
irb(main):006:0* class FooDescendant < Foo
irb(main):007:1> def h;1;end
irb(main):008:1> def e;1;end
irb(main):009:1> def ll;1;end
irb(main):010:1> def o;1;end
irb(main):011:1> end
=> nil
irb(main):012:0> FooDescendant.get_meths
=> [:h, :e, :ll, :o]
So if the author of Test::Unit wanted to perform tests in the order
that they were defined, it would be perfectly possible without
changing the existing interface. I just don’t think it would be a
good idea.
OK, I accept that methods aren’t ordered at run time and, therefore,
depending on their lexical order is wrong. I have rewritten my test
case so it has no dependencies on the order of execution.
Nevertheless, Test::Unit does take the trouble to impose an order on
the test methods. I wonder why?
Regards, Morton
On Aug 25, 2006, at 5:47 PM, Morton G. wrote:
Request for clarification.
Are you asking us to define a class or a top-level conversion method?
The quiz asks for a class, yes.
If it’s a class you want, beside initialize, what methods are you
asking for?
#initialize and #to_s plus anything else you deem cool.
Also, should ‘initialize’ accept mixed argument sequences?
I’ll leave that to your judgement.
James Edward G. II
On Aug 31, 2006, at 4:20 PM, Daniel M. wrote:
on the order they’re executed in (I actually think that Test::Unit
irb(main):006:0* class FooDescendant < Foo
that they were defined, it would be perfectly possible without
changing the existing interface. I just don’t think it would be a
good idea.
Harder than you think:
class AbstractTestCase < Test::Unit::TestCase
def test_one() end
end
class TestClassOne < AbstractTestCase
def test_some_thing() end
end
class TestClassTwo < AbstractTestCase
def test_some_other_thing() end
end
Handling this correctly will take more code than it is worth. Simple
is better.
–
Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
On Aug 25, 2006, at 8:49 PM, James Edward G. II wrote:
On Aug 25, 2006, at 5:47 PM, Morton G. wrote:
Request for clarification.
Are you asking us to define a class or a top-level conversion method?
The quiz asks for a class, yes.
Thanks for the clarification. Rereading the OP more carefully, I see
this is explicitly specified in the bulleted rules. I got thrown off
course by following sentences, which precede the rules:
For example, suppose a musician plays at a certain venue on Monday,
Tuesday,
Wednesday, and Saturday. You could pass a list of associated day
numbers to your
object or method, which might return “Mon-Wed, Sat”.
To me, the second sentence doesn’t make a lot of sense in the context
of a DayRange class. Something that takes a list of numbers and
returns a string, suggests a top-level conversion function.
Regards, Morton