In a recent IBM developerWorks article, JUnit 4 vs TestNG, Andrew Glover compares features of the JUnit 4 and TestNG frameworks, and concludes that while JUnit 4 contains many improvements over its older predecessor, TestNG still provides features not available in JUnit 4. Glover's article points to the key differences in testing approaches in the two tools:

Where the frameworks differ is in their core design. JUnit has always been a unit-testing framework, meaning that it was built to facilitate testing single objects, and it does so quite effectively. TestNG, on the other hand, was built to address testing at higher levels, and consequently, has some features not available in JUnit.

One easy-to-appreciate difference is that TestNG seems to be more flexible in how tests are declared—for instance, by not forcing static setup methods. But even more flexibility is provided by how tests are executed. For instance, TestNG allows the declaration of test dependencies, making it more convenient to run many tests that depend on each other:

Imagine a test suite that tests a Web application that requires a login. You might work around JUnit's isolationism by creating a dependent method that sets up the entire test suite with a login to the application. Nice problem solving, but when the login fails, the entire suite fails too -- even if the application's post-login functionality works!... Unlike JUnit, TestNG welcomes test dependencies through the dependsOnMethods attribute of the Test annotation. With this handy feature, you can easily specify dependent methods, such as the login from above, which will execute before a desired method. What's more, if the dependent method fails, then all subsequent tests will be skipped, not marked as failed.

Parametric testing is another TestNG feature the article highlights:

In JUnit, if you want to vary the parameter groups to a method under test, you are forced to write a test case for each unique group. This isn't so inconvenient in most cases, but every once in a while, you'll come across a scenario where the business logic requires a hugely varying number of tests... JUnit testers often turn to a framework like FIT in this case because it lets you drive tests with tabular data. But TestNG provides a similar feature right out of the box. By placing parametric data in TestNG's XML configuration files, you can reuse a single test case with different data sets and even get different results. This technique is perfect for avoiding tests that only assert sunny-day scenarios or don't effectively verify bounds.

In his recent interview with Artima, Next-Generation Testing with TestNG, TestNG creator Cedric Beust pointed out that among the TestNG team's key priorities is improving integration with IDE tools, although TestNG already has plug-ins for NetBeans, Eclipse, and IntelliJ IDEA.

What JUnit 4 limitations have you encountered? And what kinds of tests would you like to run that are currently hard to do with JUnit?