From: Eric Hodel <drbrain@...7.net>
Date: 2006-09-01T13:56:23+09:00
Subject: Re: Test::Unit gotcha

On Aug 31, 2006, at 4:20 PM, Daniel Martin wrote:

> Eric Hodel <drbrain@segment7.net> writes:
>
>> On Aug 30, 2006, at 6:16 PM, Morton Goldberg 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.

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 Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com