[ruby-core:17756] Re: Release Plan: Ruby 1.9.0-2

On Jul 12, 2008, at 18:59 PM, Kouhei Sutou wrote:
> I stop to object that Test::Unit is replaced with miniunit.
> Because nobody objects it except me. It will mean that my
> opinion doesn't make sense. If Matz says 'go', Test::Unit
> will be replaced with miniunit.
>
> I'll write my opinions in this mail below. I'm happy if my
> opinions are considered a bit in the future. It's OK for me
> if they aren't considered.
>
>
> In <[e-mail]>
>  "[ruby-core:17389] Re: Release Plan: Ruby 1.9.0-2" on Tue, 24 Jun  
> 2008 10:21:45 +0900,
>  Ryan Davis <[e-mail]> wrote:
>
>>> * miniunit isn't extensible.
>>
>> false. it is ruby. it is just as extendable as test/unit, if not  
>> more,
>> since it is cleaner.
>
> It seems that test/unit isn't easy to extend. So miniunit
> isn't easy to extend. An example is below.
>
> e.g. active_support/testing/setup_and_teardown.rb:
>
> [...]
>
> "ugly hacks" as I said means that overriding existing method
> with using internal API and aliasing it. Example internal
> API is add_failure for test/unit case, runner.puke for
> miniunit.
>
> If test/unit and/or miniunit are/is easy to extend,
> active_support/testing/setup_and_teardown.rb doesn't need to
> overriding existing run method.

I think this is a poor example.

The ugly hacks Rails makes for test/unit and miniunit would not be  
necessary if they would create a Rails::TestCase.  This would be very  
pretty in both test/unit and minunit if they would switch to a  
subclass and modules to add additional setup and teardown for whatever  
extras they need.

Rails has an unhealthy and unnatural fetish of aliasing methods and  
replacing them instead of using the more-natural inheritance  
mechanisms ruby provides.  (I believe there would be no difference  
between miniunit ugly hacks and test/unit ugly hacks using subclassing  
and modules.)

>>> miniunit doesn't provide extensible interface because it
>>> introduces complex mechanism. But we need it to avoid
>>> ugly hacks.(*) If miniunit keep simple, we will be dirty.
>>
>> I disagree. I've found a number of people (besides just me) that find
>> extending miniunit to be MUCH MUCH easier than test/unit. I rely on
>> basic idiomatic ruby to make miniunit much more approachable. See  
>> Phil
>> Hagelberg's previous email as evidence.
>>
>> Here is a real world (idiomatic) example of test/unit extension vs
>> miniunit:
>>
>> [...]
>
> I couldn't understand why test/unit version is:
>
>> [...]
>
> We can write it same as miniunit version:
>
>> [...]

Perhaps the example was too simplistic.  I have found making a good,  
user-friendly custom assertion failure message awkward in test/unit.

>>> (*) How do we add new command line option? How do we get
>>>   colorized output? How do we get diff between expected
>>>   and actual values? Need another filter command? Need to
>>>   overriding existing methods? It doesn't conflict with
>>>   other extension?
>>
>> And you think that these are addressed better in test/unit? Tell  
>> me...
>> where in the files below does colorized output go? How about
>> commandline options? Filtering?
>>
>> [...]
>>
>> % find lib/mini -name \*.rb | xargs wc -l
>>       31 lib/mini/mock.rb
>>       82 lib/mini/spec.rb
>>      436 lib/mini/test.rb                      # ALL HERE
>>      549 total
>
> colorized output:
>        127 lib/test/unit/ui/console/testrunner.rb # ALL HERE
>
> commandline options:
>        220 lib/test/unit/autorunner.rb # ALL HERE
>
> IMHO, putting all features in a large file isn't related to
> easy to extend.

There's 347 lines of output and commandline option handling in test/ 
unit.  That's 80% the line count of miniunit's entire functionality.