- 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
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.
