In-container testing - JUnit in Action - page 132

run in the container in which you'll deploy them. The tests can't verify the interac-
tion between components and container. The tests also don't test the interaction
between the components themselves as they run in the container.
You still need a way to perform integration tests. Writing and running functional
tests could achieve this. The problem with functional tests is that they're coarse
grained and test only a full use case—you lose the benefits of fine-grained unit test-
ing. You won't be able to test as many different cases with functional tests as you will
with unit tests.
There are other disadvantages to mock objects. For example, you may have many
mock objects to set up, which may prove to be considerable overhead. Obviously, the
cleaner the code (small and focused methods), the easier tests are to set up.
Another important drawback to mock objects is that in order to set up a test, you
usually must know exactly how the mocked API behaves. It's easy to know the behavior
of your own API , but it may not be so easy for another API , such as the Servlet API .
Even though containers of a given type all implement the same API , not all con-
tainers behave the same way. For example, consider the following servlet method:

public void doGet(HttpServletRequest request,
HttpServletResponse response) {
response.setContentType("text/xml");
}
This example seems simple enough, but if you run it in Tomcat ( http://tomcat.
apache.org/) and in Orion prior to version 1.6.0 ( http://www.orionserver.com/ ),
you'll notice different behaviors. In Tomcat, the returned content type is text/xml,
but in Orion, it's text/html.
This is an extreme example; all servlet containers implement the Servlet API in
pretty much the same way. But the situation is far worse for the various Java EE API s—
especially the EJB API . Implementers can interpret an API specification differently, and
a specification can be inconsistent, making it difficult to implement. In addition, con-
tainers have bugs; the previous example may have been a bug in Orion 1.6.0.
Although it's unfortunate, you'll have to deal with bugs, tricks, and hacks for various
third-party libraries in any project.
To wrap up this section, we summarize the drawbacks of unit testing with
mock objects:

This approach doesn't test interactions with the container or between the com-
ponents. It doesn't test the deployment of components.

■

It requires excellent knowledge of the API to mock, which can be difficult
(especially for external libraries).

■

It doesn't provide confidence that the code will run in the target container.

■

It's more fine grained, which may lead you to being swamped with interfaces.

■

Like stubs, it requires maintenance when code changes.

■