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

On Jun 16, 2008, at 04:39 , Kouhei Sutou wrote:

> Hi,
>
> In <[e-mail]>
>  "[ruby-core:17273] Re: Release Plan: Ruby 1.9.0-2" on Mon, 16 Jun  
> 2008 14:54:55 +0900,
>  Ryan Davis <[e-mail]> wrote:
>
>>> Do you have/know any task to release 1.9.0-2?
>>>
>>> * critical bugs
>>> * new features
>>
>> I have not heard from Matz wrt miniunit. I'd really like to get it
>> into 1.9 in order to improve the features, speed things up, and ease
>> maintenance.
>
> I can understand that 'speed things up' but can't others.
> Can I hear about your 'improve the features' and 'ease
> maintenance'?

I've already detailed this in [ruby-core:17200].

> What are the features? Mock? On the other hand, miniunit
> reduce some features. e.g. miniunit don't handle most of
> options that are accepted by Test::Unit even if --help. Is
> it OK? It's not good thing for me. I'm using --name=XXX
> form, -v v and so on.

"[miniunit] increases the number of assertions and adds mini/spec (an  
rspec-like extension) and mini/mock (a very clean and simple mock  
framework). Providing spec and mock extensions round out the  
functionality quite nicely and allow people to test however they work  
best."

I support -n and -v. --name is too much typing. I didn't see the point  
of dragging in an option parser that was larger than my impl+test. I  
like simple. It supports everything that autotest requires and all my  
other daily usage patterns.

I can add -h.

> What is the maintenance? Improve miniunit? Keep fixing bugs?

miniunit is:

+ 1/3rd the complexity of test/unit, but provides the same  
functionality.
+ 1/5th the implementation size of test/unit
+ 1/3rd the test size of test/unit.
+ or 1/4th the size overall.

and that is with additional functionality. It'd be even more if I just  
stuck to unit testing. The code is simple and fairly clean. That is  
the maintainability I refer to. Certainly I will fix bugs if they are  
found.

> It seems that you want users to improve miniunit by a
> gem. So it seems that you don't want to improve miniunit
> itself.

I don't know what you mean by this.

I certainly intend to improve miniunit (although it seems very good  
already :D). I would also love to see more people extending it through  
gems and have designed it specifically to make extending it easy...  
something I found incredibly hard to do with test/unit (and why I  
wrote miniunit to begin with).

> If the maintenance means that you keep fixing bugs, I can't
> understand why it breaks the current Test::Unit API. We are
> using Test::Unit features that miniunit doesn't
> support. e.g. option parsing, Test::Case#run isn't defined
> and so on. Are you thinking that it's too high cost for you
> that you maintain (not improve features, just only bug
> fixes) Test::Unit with the current code base?

I certainly think that maintaining Test::Unit is too high a burden. I  
broke Test::Unit (again, INTERNAL) API because there was no method to  
the madness. I find the code to be incredibly complex for very little  
gain.

For those that need test/unit internal API (like IDEs or graphical  
test UIs), we released as a gem, but for ruby itself? I don't see the  
point of having all the pain.

I've spent less than an hour (ie, a small and reasonable amount of  
time) running 1.9 tests with both test/unit and miniunit and got the  
results within a reasonable level of sameness. Unfortunately, ruby  
testing on OSX seems to be very inconsistent, so I can't tell what's  
because of miniunit (if anything) and what isn't.

505 % tail -2 tests.before.txt tests.after.txt
==> tests.before.txt <==
4650 tests, 1659634 assertions, 37 failures, 79 errors
==> tests.after.txt <==
4610 tests, 1689855 assertions, 49 failures, 134 errors

Given this, is there any reason NOT to switch?

As an aside, I'm don't understand why you're questioning switching 1.9  
to miniunit. I thought I detailed all of this to you back when you  
expressed interest in working on test/unit (feb/mar?). None of this  
should be new (except for specs and mocks).