I read this comment in an article by Bryan Dollery at InformIT linked to a JUnit extension I was reading up on. The sentiment expressed in the article, extolling the virtues of JUnit, is one I hear a lot in books, articles and such:
"JUnit has to be kept simple, so the creators haven't added the many features that developers have requested. Instead, they built the core framework so that it was easy to extend. Now developers choose just the libraries they need."
The wording would nicely sum up JUnit's feature status in the open source world, if only it wasn't delivered with such reverence: "the creators haven't added the many features that developers have requested." Period. OK, sure, they made it easy to extend. I mean, you can extend TestCase (obviously), but extending junit.framework.TestCase to write regular test cases obviously isn't what is meant when people praise JUnit's small codebase, simple API, and "extensible" framework. How many of you have tried extending one of the TestRunners? Or implementing a TestListener and registering it with one of the existing TestRunners? You can't do either by pure extension because you have to work around limitations that hinder extensions from overriding the TestRunners' default OutputStream for reporting, and if you implement a TestListener you have no working way to register the listener with an existing TestRunner.
In case you didn't realize it, most of the popular "extensions" that people have made to supplement JUnit are test runners that don't extend anything in JUnit, like Ant's <junit> and <batchtest> tasks and Artima's SuiteRunner, or are specialized extensions of TestCase or TestDecorator, such as Log4Unit, JUnitPerf, XMLUnit's XMLTestCase, etc.
JUnit's greatest contributions to Java development and testing are the Assert and TestCase classes. Kent Beck and Erich Gamma established the de facto standard API for unit testing in Java with those two classes, really. They ship JUnit with a couple simple little test runners, which were enough to get people hooked (those and the concurrence of JUnit's rise to fame with Martin Fowler's Refactoring book and the XP series of books). JUnit has some nice examples of design pattern usage in the code, and it's package design is a perfect acyclic dependency graph. But don't let anyone tell you it's "easy to extend" or lead you to think it's some jewel of extensible object oriented magic that's so perfect it needn't be polished up.
The fact is, JUnit is pretty much abandoned out there on Sourceforge. Call it a virtue if you want, but don't tell me JUnit 3.8.1 is complete or even "good enough." It can hardly be called an open source project in the same sense as something like Eclipse, Apache Geronimo, Jakarta Tomcat, MySQL, etc. because there are no active committers. And there won't be as long as Kent and Erich keep it locked up for fear of people actually implementing some of the many features that people have asked for. So JUnit is open source, but I wouldn't call it an open source project right now.
Anyway, until then, at least the source code is released with JUnit so you can fix bugs and write extensions yourself if you need to. Next topic.
Previous Topic
