This post originated from an RSS feed registered with Ruby Buzz by Ryan Davis. Original Post: move over test/unit Feed Title: Polishing Ruby Feed URL: http://blog.zenspider.com/index.rdf Feed Description: Musings on Ruby and the Ruby Community... Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Ryan Davis Latest Posts From Polishing Ruby

I love testing. I just do. I do it all the time. I'm a big TDD dork. I push for it because it makes my life and my code easier. That said, there are times when I really dislike test/unit. It is a lot bigger and more complex than it needs to be.

Working on metaruby it is our very first hurdle for every class we try to reimplement (nuke all of the methods in Array and see how far YOU get :P) We have to do a phase where we figure out what essential core methods are needed for test/unit to run the rest of our tests.

Sometimes, "essential" is subjective and it gets in our way.

Regardless, test/unit is 3300 lines of complex code for a system that as originally described is not that complex at all. To be fair, test/unit has a lot of bells and whistles, but I'm guessing most people never ever touch most of them. Me? I use the basics + regular expression filtering. That's it. No GUI, nothing extra. And it does great (*).

So, while working on BFTS (Big "Formal" Test Suite--our fork/port of the rubicon test suite), I wrote a drop-in compatible replacement for test/unit. This will let us have a much smaller set of essential core methods for our metaruby work. I've got the newly ported tests for Array, Hash, String, and Time running with it.

So... the clencher? What really makes me love this code to the point that I smile every time I read it? It is a beautifully clean 71 LOC long!!! (92 with whitespace and comments!) The bells and whistles in test/unit might be nice, but I highly doubt you get 36x (92 vs 3300) the functionality from it.

*) My only complaint about test/unit, besides its complexity, is the error when you have a TestCase subclass that doesn't have a test method in it. That is just wrong in my opinion. I don't think you get that much out of that type of error, and I don't have a single project that doesn't refactor test code into an abstract superclass.