[QUIZ] DayRange (#92)

[Morton Goldberg]

Oops, I misunderstood them. My bad. The situation you described
*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

 

[Eric Hodel]

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"]

 

[Rick DeNatale]

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.

 

[Morton Goldberg]

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

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 Hodel]

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, ]

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.

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.