Re: Test::Unit maintainer

Kouhei Sutou wrote:

> Do your test cases call super in setup?

I use Rails fixtures, and they bond with their test suites in some curious way I 
have not yet deciphered. Then I use non-standard test extensions, such as View 
Tests. If I write a setup(), I often discover fixtures break until I add that super.

Yet the majority of setup() calls out there, including mine, do not call super.

Can we think of a pre_super that's for our internal use?

 > It's difficult to
> force users to call super because TestCase#setup has not
> been forced to call super.

Force the users to write it if they need it!

If we really need all unit tests, everywhere, to call super, we can we emit a 
warning if we discover a child class method overrides a parent class method? How 
about this:

   def setup  #  parent class
     @dead_man_switch = true
   end

   def run(result)
     setup
     warn('setup overrode without super!') unless @dead_man_switch
   end

There might be a leaner way. (A "dead man switch" is a switch that goes hot if 
the man operating it dies. That way killing someone, such as a security guard, 
will automatically raise an alarm...)

>> That's why I said "like"! Folks will need many hooks into the system.
>>
>> In general, RubyUnit's innards remind me of "Java-style Ruby". Nothing personal. 
>> But Ruby generally lets us extend so much more subtly, without all those hooks 
>> hanging out.
> 
> What are 'those hooks'? Broken down methods or
> setup/teardown methods?

Yes to both. "Hooks" is jargon from /Design Patterns/ for Template Method, which 
is our pattern here.

Also remember the size of the RubyUnit community - it's best not to party with 
the source! We should instead set goals that take years to achieve...

--
   Phlip