JW Blogs: The cult of Spring
Obviously when you're up and coming, you gun for those already on top. Nonetheless, JW blogger Josh Fruhlinger is charmed by Web4J creator John O'Hanley's recent comments about the Spring framework, which he notes "has met with a disturbing lack of criticism ..."

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters

Email Address:

A lightweight nonintrusive EJB testing framework

Bring your EJB 2.0 applications in line with testing best practices

Enterprise JavaBeans (EJB) has become increasingly less popular among J2EE developers in the last couple of years. Many factors contribute to this poor reputation, but high on the list is the fact that EJB components are inherently difficult to test.

The EJB 3.0 Expert Group recognizes that testing EJB applications proves difficult, and the upcoming specification is expected to address the issue. However, at the time of this writing, EJB 3.0 is still in early draft review (see Resources). The specification's finalization and widespread implementation by vendors is still many months away.

In a typical current EJB application, business logic hides behind session-bean facades. For performance reasons, a large portion of the code running on the EJB container is exposed only via EJB local interfaces, which are inaccessible to a suite of JUnit tests running on a separate JVM. In the case of container-managed persistence (CMP) entity beans, much of this code also relies on container-provided services, making it virtually impossible to run outside the EJB container. For example, the EJB CMP bean classes that the application developer writes are themselves abstract classes, the concrete implementations of which are provided by the container. In short, creating a suite of comprehensive unit tests for an EJB-based application creates a real headache for any proponent of test-driven development (TDD).

Two approaches tackle this problem. First is the use of mock objects, which involves a dummy implementation of the EJB API, that can run outside the EJB container. An example is MockEJB. The second approach involves the use of an in-container testing framework such as Cactus, from the Apache Jakarta Project. Here, the idea is to deploy the test code onto the container and run the tests in the application's real execution environment.

In this article, I present a framework that follows the in-container test approach, but has the advantage of being simple to understand and use. It involves the following:

  • An additional stateless session bean
  • An interface that must be implemented for individual tests
  • An implementation of this interface for each test to be run
  • A JUnit base class to allow integration with the suite of tests to be executed on the client
  • A small modification to the build environment


The framework

Before we discuss how the framework works, let's first consider our requirements for an EJB testing mechanism:

  • The mechanism should be nonintrusive. That is, we should be able to deploy it with minimum interference from the application's development build environment.
  • Ideally, there should be minimal dependencies on additional external libraries. We'd rather not have to add jar files to the application server's classpath or to the EJB jar file's lib directory to enable the framework.
  • The test framework should integrate well with the JUnit tests that run on the developer's client machine.
  • Writing the tests themselves should be easy.


Let's now explore how our framework is implemented.

The test interface

A key component in the framework is the interface ContainerTest, the test interface for which any implementation class constitutes a test case. The methods in the test class execute on the EJB container, and are invoked by the UnitTester EJB, which I discuss shortly.

ContainerTest defines the following methods:

 public void setUp(Object[] args) throws Exception;
public boolean doTransaction();
public void runTest(Map resultMap) throws Exception;
public void afterTransaction(Map resultMap) throws Exception;
public void tearDown(boolean succeeded) throws Exception;



The test interface models a JUnit test's lifecycle, with setUp() and tearDown() methods. These methods can be used to set up state before running the tests and revert state afterwards. Note that arguments can be supplied to the setUp() method from the client in the form of an Object array, although this is optional.

1 | 2 | 3 | 4 | 5 |  Next >

Discuss

Start a new discussion or jump into one of the threads below:

Subject Replies Last post
. Good article
By Samudra Gupta
2 05/16/08 06:28 AM
by Anonymous
. Ejb3Unit supports out of container testing
By
0 10/14/07 09:43 AM
by Anonymous
. A lightweight nonintrusive EJB testing framework
By JavaWorld
1 05/24/07 12:15 AM
by Anonymous
. Another ejb test framework...
By nicolas frank
1 03/02/06 05:44 PM
by Anonymous


Resources