Kouhei Sutou wrote:

> I'll do so. And some property set methods will be added. e.g.:
> 
>   class MyGenericTestCase < Test::Unit::TestCase
>     setup # or other name
>     def my_setup
>       ... # will be called even if #setup is overrode.

I suspect folks typically use 'super' there, right?

In general, use Test-First, and use the unit tests on RubyUnit to prove you need 
a feature, and to show these "overridden" hooks in action!

>     end
>   end

>> Esthetically, setup is no longer in the same method as teardown.

Note I meant that's _bad_ aesthetics. My refactor could use more blocks calls 
and such to fix it. The two rescues (one around setup and run_case, the other 
around teardown) might merge together...

 >> The benefit is
>> one could add a method like skip() by overriding only run_case, without then 
>> inflicting their change on all the other statements in there.
> 
> I'll add the method as built-in.

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.

-- 
   Phlip