RE: [ANN] TestUnit 0.1.3

David Corbin [mailto:[e-mail]] wrote:

> Can you elaborate on the features that TestUnit offers that rubyunit 
> doesn't?

First of all let me say, this reply is not intended to be a critique of
RubyUnit's design; Masaki made the decisions he believed were right at
the time based on his knowledge, and I don't want to question that.
However, I've been asked this question a lot, and I think those who are
happily using RubyUnit deserve some kind of an explanation before they
take the time to learn the differences in Test::Unit and switch to it
for new development.

Ron Jeffries and I corresponded on exactly this topic a while back, and
here's the answer I put together for him, along with some additional
tidbits...

For every day basic testing, Test::Unit doesn't offer much more than
RubyUnit... as a matter of fact, I can't come up with one concrete
feature off the top of my head (other than the fact that I like some of
its aesthetics more, but then, I created it, so that's expected).
However, when you want to do something special, Test::Unit provides some
definite benefits. Maybe I can describe them best like this:

Simplicity - RubyUnit is based on JUnit, but Ruby is more like Smalltalk
than Java. Thus I went back to the original sunit docs and built what's
now Test::Unit from that basis. I've tried to keep it as simple and
elegant as I possibly can, and perhaps I've succeeded. I know that when
I want to extend it or change it, I find it very easy, and I don't think
that is only due to the fact that I know it so well.

Communication - I like code that is easy to follow and clear, so I've
written Test::Unit to read well. In particular, the method names try to
be very clear. You can be the judge of whether I've succeeded. I haven't
heavily studied RubyUnit, so perhaps it succeeds here, too.

Feedback - How much more feedback can you have than testing a testing
framework with itself? Test::Unit is written completely test-first. I
know there are holes in the tests, but there are far fewer than if it
had not been tested at all, or tested after the fact. RubyUnit's tests
have been lately added; when I first started on what is now Test::Unit,
I do not think it had any.

Courage - Hopefully all of those things give people courage to fiddle
with Test::Unit to fulfill their own needs, and hopefully that gives
people more courage to think they can write tests for all their code.

So I guess the things I like in Test::Unit have more to do with
philosophy, aesthetics and design than with hard cold features. However,
I won't claim to have used RubyUnit enough to definitely identify
features that Test::Unit has that it lacks. Perhaps you'll find some
yourself. On the gripping hand, if you find features that RubyUnit has
that Test::Unit lacks, let me know. I'm always willing to improve.

The other thing to note is that Test::Unit will be going in to the
standard Ruby distribution, and new development will be focused around
it (RubyUnit has frozen at 0.5.4). Thus, at this point, there are
definite advantages to doing new development with Test::Unit.

Does that answer the question? I'm certainly willing to discuss and
write about the subject further. Perhaps there are other questions that
this explanation raises; bring them to the table and I'll do my best to
answer them.


Nathaniel

P.S. David, I was going through my Lapidary/Test::Unit email
correspondance looking for the letter to Ron and I came across your
private email that asked this very question back in early January. Then
I realized I had completely neglected to reply to it! <hangs head>
Sorry; hopefully this answers the question, if very, very late.

<:((><
+ - -
| RoleModel Software, Inc.
| EQUIP VI