TestNG has been on my “must play with that some day” list for quite some time. Though I’m yet to write any significant tests with it, I was lucky to recently get some exposure to it to prod me along. This came in the form of support for Maven 2 contributed by Jesse Kuhnert, who not only did the initial patch but continually and patiently prodded me to look at it. I’d also listened to Cédric’s JavaPosse podcast (or at least the first half, it seems to cut all the old ones off in the middle). I’d also started to get the IDEA plugin, assuming I got the right one
since the web page just said “get the plugin from the plugin list”, and there are two, neither of which seem to be related to the project. The other was a generator and I now have the little TestNG logo in the configurations dialog, so I think I’m good to go.
The main reason I had put it off for so long was that I hadn’t yet learned much about actually using TestNG and I knew I was going to have to make some changes to our test runner code called Surefire that has been around a long time and not evolved with the Maven 2 architecture. The patch for TestNG worked out of the box, but didn’t (couldn’t) integrate with other features.
There were some rough edges along the way. Since the patch was using a few internal APIs from TestNG that were public, upgrading through releases that had come since constantly broke the code. Might be time to introduce them to Clirr, another of my favourite new toys 🙂
However, the refactoring is now done and the TestNG code all revisited, and we’ve landed support that is comparable to JUnit (3) and the basic POJO test runner that is built in. It supports all of the fork modes (none, once for the whole suite, or fork for each test set), but more importantly integrates with anything else in the build lifecycle, such as Cobertura, without any additional configuration. This required very little TestNG specifics, so hopefully the basis is now there for other providers, as we start to see requests for JUnit 4 roll in. This is pretty satisfying, as we get to see the fulfilment of Maven’s promised build knowledge reusability in action.
Once released, using TestNG tests is just a matter of including:
And from there you can run the usual mvn test, mvn cobertura:cobertura, mvn clover:clover, etc. Of course, you can customise them to enable things such as parallel test execution and using TestNG’s XML suite definition files instead of the normal includes/excludes mechanism.
Another great thing is that you can try out TestNG immediately, even with your JUnit tests in place – the test runner finds each Java file and sets the JUnit flag for tests if appropriate so that they can be mixed in the directory with TestNG tests.
There are some instructions for those that might be game enough to test it before the release, but it is not quite there yet and there are still some minor bugs to be resolved. Hopefully, these won’t hold it up for too long.
All in all, I think this is a great development and I certainly anticipate trying out TestNG on my current project. Just as soon as I get through all the mail I haven’t read while I was playing around with it.
Technorati Tags: maven