Verify the World

In the world of unit testing frameworks for Java, there are really only two that truly stand out: JUnit and TestNG.

While JUnit is the de-facto standard, and rightly so (it’s been imitated in every language from C# to Perl).  JUnit provides a comprehensive assertion library, integrated support for build management tools like Ant and Maven, as well as just about every continuous integration tool worth mentioning, and even IDE support for the most popular Java IDEs.  However, there are a few areas where JUnit just doesn’t meet every developer’s needs.

Enter TestNG.  TestNG (the “NG” stands for “Next Generation”) was developed as a replacement for JUnit 3.x, which, at the time was found to be very restrictive.  JUnit test classes had to extend org.junit.TestCase, setUp() and tearDown() methods had to be named just that and contain empty-argument signatures, to name just a few of the limitations.  TestNG, on the other hand, used the whiz-bang new J2SE 5.0 Annotations paradigm to bless any method you please as a unit test, set-up method, or otherwise.  JUnit was quick to follow suit in 4.x.  What JUnit still can’t buy you these days is parallel execution support.  Much of the value of unit tests is that they are fast.  However, in a large application, you could have thousands of unit tests, and the amount of time spent running each in turn could negate the benefit of having them in the first place.

Re-enter TestNG in billowing cape and tights.  With TestNG, all your unit tests can run in parallel using a configurable thread pool, with fail triggers that watch execution time or run the same test multiple times in a row, reporting a failure only if the test fails more than a certain percentage of executions.

Another really cool feature of TestNG is the “data provider” method.  Unit tests are great, because they can exercise a method in your class-under-test and expect a particular result.  However, that method would probably produce a deterministic result for any number of different data.  Using a data provider, you can call your test method over and over again with different arguments, exercising your method-under-test with a wide range of inputs!  Just change your test method signature to take in whatever input values you’d like to apply to your method-under-test.  Then, add the dataProvider=”someString” attribute to your @Test annotation.  Now, create a new method with the @DataProvider annotation and a matching name=”someString” attribute.  A data provider method takes no arguments and returns either an Object[][] or an Iterator<Object[]>.  (I find the latter to be more useful, as it conveniently allows you to use a Collection<Object[]> within the method, and then call iterator() in the return statement.) The first dimension of the array is the list of argument sets.  The second dimension of the array the actual list of arguments.

You’re all set!  When your test method is executed, it will be run once for each entry into the data provider’s return object!  Now that’s some good exercise for your method-under-test!

Like what you’re reading, but already using JUnit 3 or 4?  The official distribution of TestNG comes with a conversion mechanism that will run through your code and update all your JUnit tests to TestNG tests!  How cool is that??

There are more cool features of TestNG than I can get into, here.  I’d recommend reading the official page thoroughly.  For my purposes, I give TestNG two thumbs up!

Reblog this post [with Zemanta]