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.

-- 
s=%q(  Daniel Martin -- martin / snowplow.org
       puts "s=%q(#{s})",s.map{|i|i}[1]       )
       puts "s=%q(#{s})",s.map{|i|i}[1]