The BileBlog

Next up is Cedric’s talk about TestNG. TestNG for those who don’t know (and why the hell don’t you know what it is, given that Cedric whores it at every chance?), it’s basically an improved and less fucked up version of JUnit.

Now, TNG won’t really address any of the flawed premises of JUnit, it will however address the absolutely retarded and childish way that JUnit is implemented.

The talk kicks off by pointing out the positives of JUnit, but quickly launches into describing how anyone who relies on such a brokenass piece of goatshit is basically trying to run a marathon by first chewing off one leg and blowing up the other while ramming an uncomfortably large baby jesus buttplug (yes, such an implement does exist, google it) into any number of orifices.

For the unenlightened, there’s a whole plethora of issues with JUnit. Thoughtworks cocksuckers will insist that it’s all that way deliberately and will basically slowly insert hot pokers into their dirtboxes simply because junit says so. They’ll also do it with their trademarked shiteating grin and lofty furious arm waving tactics.

These issues range from the fact that each test object is instantiated over and over again for every test method to the amusing need to use statics to maintain any sort of state across invocations. JUnit is also essentially abandonware at this point. It doesn’t really support 1.4 (no assert keyword), it relies on a static programming model (you need to use a fancy IDE, recompile, or other custom crap in order to run a subset of tests), and so on and so forth.

It’s really quite impressive, that such an abysmal product has managed to succeed so well. I’d say that that’s mostly due to the fact that it’s free (so no cost to using it) and that its underlying concepts and principles (on a high level) are very compelling and appealing to all sorts of software development approaches.

TestNG addrsses a number of these issues with varying degrees of success. For one thing, it extensively uses annotations (or jdk 1.4 javadoc comments) for metadata. I have somewhat mixed feelings about this as the jdk1.4 javadoc comment style is SO fragile (ever fucked up an xdoclet comment? It’s endless hours of joy tracking down why). However, it’s a reasonable compromise as Cedric’s initial plan of supporting 1.5 only is clearly about as useful as a project that can only be built with maven.

The runtime configuration is also captured in an xml file, rather than java source. So you’re able to specify test groups and other relationships between tests. This allows all sorts of useful crap like being able to have a specified test run order, dependent tests (test X requires Y and Z to be run first). So for example, if you have some kind of ‘verify db connection’ as the first method, you can specify that all other tests depend on it, so once the first one fails, the others are not run since we’ve had an early failure. TestNG is also designed up front to cope with plugins and extensions, so modifying its behaviour or adding to it hopefully involves less stabbing of eyes and penis mangling that working with JUnit does.

Some of the other nice features in TestNG is that you no longer have to start all your methods with ‘test’ nor extend a base class, since annotations capture the information that that hack has been put in place for.

The annotations available are a pretty rich set of controls to customise and specify test behaviour. You can for example specify a timeout on a per test basis (if this takes more than 10 seconds, soil yourself, etc).

The grouping support is actually quite powerful, since you can arbitrarily slice and dice your test into whatever groupings make sense for you. So for example, you can specify that a test is part of the ‘functional’ group, the ‘config’ group, and the ‘database’ group. You are then able to execute all tests within a particular group. There are many examples of the power of the grouping feature. Another example; you can create a ‘broken’ group that tests that are still being developed for example can belong to in order to be excluded by default (yet still show up as being skipped, so you don’t forget about them a la JUnit commented out tests). This approach craps all over the ‘never check in stuff unless all tests pass’ approach, since it correctly decouples testability from commitability, a bizarre coupling that has become quite popular recently.

All in all, a good introduction of the features of TestNG, and I’d be stunned if anyone with two braincells to rub together would, given the choice, ever pick JUnit over TestNG in future. The only question mark of TestNG’s future really is tool adoption. JUnit’s success can also be largely attributed to all the third party crap that has sprung up around it (coverage tools, IDE integration and whatnot). Of course, given how primitive and childish is it, it’s pretty easy to do all that. TestNG integration into toolsets will require more thought and consideration and well…work. Nobody likes more work, so it remains to be seen if TestNG manages to achieve that critical mass whereby users start nagging their vendors to support it and kick off the snowball effect.

This entry was posted on Friday, March 4th, 2005 at 5:56 pm and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.