On Jun 16, 2008, at 04:39 , Kouhei Sutou wrote: > Hi, > > In <F732B60B-DA6E-452A-8EB6-8E2B071294F2 / zenspider.com> > "[ruby-core:17273] Re: Release Plan: Ruby 1.9.0-2" on Mon, 16 Jun > 2008 14:54:55 +0900, > Ryan Davis <ryand-ruby / zenspider.com> 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).