Do we need an isolation layer for unit tests?

There are lots of cases where you want to use an "isolation layer", a genericized API that keeps you from being trapped in the Vendor Lock-in Anti-Pattern. This approach allows you to write to the interface provided by the isolation layer, and avoid hard-coding anything that ties you into a specific API. J2EE's Data Access Object (DAO) is arguably an example of this, though it serves other purposes as well, such as allowing you to switch persistence strategies (more on this in a little bit).

So, if you're dutifully putting your persistence behind an isolation layer... why are you writing unit tests that lock you into JUnit? Not that JUnit is profoundly defective or anything, but to disavow vendor lock-in for one aspect of your development and profoundly embrace it for another seems confused at best.

OpenSymphony founder Hani Suleiman takes a whack at this problem in Migrating to TestNG, which we feature in Also in Java Today . Discussing the hazards of moving to TestNG, he writes:

One key blocker to TestNG's adoption is the huge mass of existing legacy JUnit tests. Most projects have hundreds, if not thousands of JUnit tests already written. Another is that most IDE's include JUnit support built-in, where it is possible to run any collection tests in methods, classes, and packages.

[...]

As for migration, it is often difficult to put forth a business case for investing more than minimal time and effort in achieving this. So clearly, for TestNG to achieve wider adoption, there must be a clearly documented and easy path for migration.

In his article from TheServerSide, Hani spells out a process by which you can test the waters of TestNG, gradually or quickly moving a JUnit-based project over to TestNG. While his article is not a comparison of the two testing frameworks, he does point out some of the advantages to be enjoyed by those who complete the switch.