Skip to main content


Posted by editor on August 17, 2005 at 6:02 AM PDT

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.

In another Also in
Java Today
the Data Access Object (DAO) pattern advocates using a common API for
accessing a data source, so you can hide the implementation from the
caller. This also allows you to switch from one implementation to
another, such as from simple file-based persistence in development to an
enterprise-class RDBMS in production. In iBatis DAO, Sunil Patil
writes: "iBatis Data Access Object (DAO) is an open source framework now
hosted by Apache and targeted at solving these type of problems. It
provides you with an infrastructure for creating applications based on the
DAO pattern."

Humorously inaccurate predictions begin today's Weblogs. In

C# could be major, Calvin Austin writes: "'C# could be major', 'Microsoft C# gets an A'. These were the headlines 5 years ago... what happened?"

Pluggable ID/IDREF handling in JAXB 2.0, Kohsuke Kawaguchi writes
"it's often convenient to be able to define a sophisticated reference integrity mechanism that goes beyond ID/IDREF. Jeremy Haile, one of the JAXB users, convinced me that we should do this in the RI. While it took me a month to get back to this, I was finally able to implement it. That's what I'm going to talk about today."

Navaneeth Krishnan collects Folksonomy, Ajax FUD and crazy elevator hacks:
"If you are interested in social software, here is a discussion you must listen to. Also, "Using the XMLHttpRequest Object and AJAX to Spy On You" is plain FUD."

In Projects and

the next Jini Community Webinar is scheduled for next Wednesday, 8/24, and will feature Calum Shaw-Mackay talking about Neon, a framework for hosting agent-based components across a grid. Previous webinars' materials are also available at the webinar site.

The JavaDesktop Community project thereallm aims to "create a secure, scaleable, streamlined, semantically-rich system of standards-compliant transactions among heterogeneous entities." The developers say it is "intended to be a realization of the 'semantic web'."

bmesserer is trying to clarify Glassfish features (esp. Java EE 5/EJB3) in today's Forums:
"Okay, understand that... but wouldn't it be good if the developers provided some "starting point" on what (features of Java EE 5) they already implemented/are working on? At least _they_ should know what they did/still need to do (?). From this "feature list" it would be ok to proceed as suggested, but finding out what works by unit test, from zero, seems to me like a waste of effort (since we'd need to discover everything from zero that the developers already know). I'm well aware that this approach would result in great coverage by unit-tests but on the other hand this would mean I'd have to commit quite some time to glassfish before I can test on it... sure, I'd like to but sadly I'm paid to write _our_ application, not glassfish. If it already works more or less I may be allowed to invest some time into project glassfish but from zero? Understand my problem?"

Continuing the jump-start of the Performance forum, tmarble talks about issues related to Maximum Memory in Java:
"For windows you are limited to 2 GB... See Moazam Rajas' blog for details. Presumably this will be fixed with Vista... But then I hope that M$ changes their plans to hobble performance of OpenGL. On Linux and Solaris we can get very close to the 4 GB barrier with the 32-bit JVM and beyond with the 64-bit JVM."

In today's
News Headlines

Registered users can submit news items for the href=""> News Page using our
news submission
. All submissions go through an editorial review before being
posted to the site. You can also subscribe to the href=""> News RSS

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href=""> events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

Do we need an isolation layer for unit tests?