Testing Outside the Container

At JavaOne I've heard a talk by Jim D'Ambrosio on the problems of EJB testing. Frequently, unit testing is done after deployment onto an application server which creates a set of nuisances:

• configuration and setup is time-consuming
• debugging is complicated (remote debugging)
  
• Too much time waiting for the server to start
• Bugs in other areas slow you down

Jim concludes that it is better to unit test EJBs outside of the application server. For this purpose, mock objects can simulate the EJB container's runtime environment. EJBs are unit tested as plain Java objects. This should make developer's lives easier and more productive (see the article Streamlining Your EJB Tests With MockEJB).

These arguments are equally true for ESB service development! Deploying service types into an ESB container before unit testing them makes the development process slow and complicates debugging. Mock objects to the rescue! One problem remains though: there are no off-the-shelf mock object libraries for ESB containers. ESBs are still less wide-spread and there's no standardised API yet for ESB service implementations.

In my current project we are working with the Sonic ESB container. Given the lack of mock libraries for this container, we just built one ourselves. We are now in a position to simulate the Sonic ESB Service Container and therefore greatly improved our development lifecycles and code quality.

Because there’s no time required to start up the container (and no resources consumed), this streamlines testing -- a fact that makes test-driven development feasible. Since services are tested in isolation, there’s no dependency on other system components. Sometimes we test several services within one unit test when they act as counterparts of each other (e.g. FileDropServices/FilePollServices, FTPPut/FTPGet).

However, this approach is no panacea for developer woes: Integration testing must still be done on the container.