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.
 
 
 
 
 
Search WWH ::




Custom Search