Automating EJB Unit Testing

Testing EJB is different

Container matters

Enterprise Java Beans, or EJBs, cannot be tested on their own as can plain Java classes. There are additional steps to deploy them to an EJB container before they can be tested. This means that our testing process must include the additional process of deployment and re-deployment of EJBs. The deployment must be automated as well.

There are some arguments on the differences between running the EJB test client inside or outside of the EJB container. If you write your EJB test code with JUnit and run the test client directly from your IDE, or even from the command line, that is an outside container testing. On the other hand, you can use other test frameworks -- such as Apache Cactus -- to simulate in-container testing. There are also other similar approaches, such as a servlet interface, as introduced in the article "Test Infect Your Enterprise Java Beans" (see Resources).

Although using a server-side testing framework to test EJBs looks more comfortable, from our experience in terms of unit testing, the outside container testing is safe enough for programmers to prove the beans are still working as expected during development. That is all we want in Extreme Programming, or XP. (We will elaborate our scope of unit testing in the next section.) We have not encountered any problems regarding this issue; in fact, we appreciate its simplicity and speed.

Database Matters

Entity beans are actually data objects. Entity bean manipulations such as creating new entity beans, updating entity beans or deleting entity beans, are eventually converted to CRUD database access code, producing the same results as using direct JDBC access. This produces a few issues with the test data.

Duplicate records

You cannot have duplication data for primary key columns when testing entity beans, otherwise the database's intrinsic mechanism will reject the data. (This can be a test, though.) You must design your test suite to avoid this situation.

Dependent data

In real life, most of data in the database has relationships. Creating new data may require some dependent data to exist. Deleting data with dependencies may not be allowed.

Large data

Sometimes the data set is really big.

Visual Inspection

When developing EJBs, most programmers will check the result of testing. For example, the creation of a new entity bean may be tested by visually inspecting the database. This is slow and inaccurate.

This article presents a few techniques to avoid those problems by properly designing initial test data and by using simple JDBC access code.

The Scope of Unit Testing

Automated unit testing is a foundation practice in XP. Without this, it is almost impossible to practice other behaviors, such as continuous integration and aggressive refactoring. Before we propose our solution, we want to give a scope for the unit testing in our context. When we say unit testing as in the title of this article, we actually mean a little bit more than the original rigorous definition of unit testing, which is commonly limited to the class level in Java.

In XP, what we really want to achieve is to make sure everything still works properly during continuous integration and after aggressive refactoring. In the context of EJB testing, our unit testing will cover not only simple methods inside a bean (entity bean and session bean), but also small subsystems such as a session (façade) bean. In the latter case, multiple entity beans are accessed and more than one function may be tested in a simple unit test case. In our opinion, a session bean with several highly cohesive entity beans forms a good unit, making it a good candidate for the assembled unit for unit testing.

In this case, we agree on the new definition given by Sheldon Wosnick from IBM in his article on Cactus (see Resources), integration unit testing -- "a compromise between code logic unit testing and function unit testing," in his words. We will not discuss test-first or test-driven techniques in this article. Comprehensive resources on unit testing can be found at www.junit.org .

Two Scenarios

There are two common scenarios where EJB unit testing may be performed: during development and during integration. By "development," we mean at the time of coding. The developer may want to run the unit test at any time after some code changes. This testing is normally performed on one or a few beans at a time.

By "integration," we mean at the time beans from different developers are integrated together and integration test suites are run, since beans may behave differently when assembled together. This is normally adopted by XP teams from the idea of continuous integration. Integration tests may be run every day or even every hour.

We will focus on development unit testing in this article. However, the idea and even the same code can be used in integration tests. For example, selective session bean test cases can be used in an integration test suite. The best part of this approach is that you don't even need two sets of test suites for unit testing and integration testing, in the case of EJB testing.

Automating Deployment Process

In both development unit testing and integration unit testing, beans must be redeployed before performing another round of testing. This is the process of removing the deployed bean from a container and redeploying it. There is also a technology called Hot Deploy. Unfortunately, not all EJB containers have implemented this feature well.

For development unit tests, automating the deployment process may not be necessary, since the tests normally just modify one or a few related beans. A manual redeployment may be faster.

However, in integration unit testing, a complete and fully automated deployment process is crucial to the whole automation process. Without that, the continuous integration in EJB development is not possible. All of the EJB container providers provide some kind of command-line tools for the EJB deployment, e.g., the XMLConfig for IBM WebSphere. With the help of Apache Ant, you can organize perfect scripts to automate this deployment. We are not going to elaborate on this subject, since the tools from different vendors are quite unique and the industry has not yet produced a standard.