Java Reference
In-Depth Information
8.4.3
In-container testing pros and cons
So far, we've described the advantages of in-container unit testing. But there are also a
few disadvantages, which we now discuss.
S
PECIFIC
TOOLS
REQUIRED
A major drawback is that although the concept is generic, the tools that implement in-
container unit testing are specific to the tested
API
, such as Apache Jakarta Cactus for
Java
EE
testing. If you wish to write integration unit tests for another component
model, chances are such a framework exists. With mock objects, because the concept
is generic, you can test almost any
API
.
N
O
GOOD
IDE
SUPPORT
A significant drawback of most of the in-container testing frameworks is the lack of
good
IDE
integration. In most cases, you can use Ant or Maven to execute tests, which
also provides the ability to run a build in a continuous integration server (
CIS
, see chap-
ter 11). Alternatively,
IDE
s can execute tests that use mock objects as normal
JU
nit tests.
We strongly believe that in-container testing falls in the category of integration
testing. This means that you don't need to execute your in-container tests as often
as normal unit tests and will most likely run them in a
CIS
, alleviating the need for
IDE
integration.
L
ONGER
EXECUTION
TIME
Another issue is performance. For a test to run in a container, you need to start and
manage the container, which can be time consuming. The overhead in time (and
memory) depends on the container: Jetty can start in less than 1 second, Tomcat in 5
seconds, and WebLogic in 30 seconds. The startup overhead isn't limited to the con-
tainer. For example, if a unit test hits a database, the database must be in an expected
state before the test starts (see database application testing in chapter 17). In terms of
execution time, integration unit tests cost more than mock objects. Consequently, you
may not run them as often as logic unit tests.
C
OMPLEX
CONFIGURATION
The biggest drawback to in-container testing is that tests are complex to configure.
Because the application and its tests run in a container, your application must be
packaged (usually as a
WAR
or
EAR
file) and deployed to the container. You must then
start the container and run the tests.
On the other hand, because you must perform these exact same tasks for produc-
tion, it's a best practice to automate this process as part of the build and reuse it for
testing purposes. As one of the most complex tasks of a Java
EE
project, providing
automation for packaging and deployment becomes a win-win situation. The need to
provide in-container testing will drive the creation of this automated process at the
beginning of the project, which will also facilitate continuous integration.
To further this goal, most in-container testing frameworks include support for
build tools like Ant and Maven. This will help hide the complexity involved in build-
ing various runtime artifacts as well as with running tests and gathering reports.