want to say your product supports multiple Enterprise servers to allow for sales to a wider
range of clients.
Arquillian also supports remote integration testing. In some cases, integration testing with
in-memory containers and resources isn't enough. In these cases an enterprise may have a
special environment setup just for integration testing. Arquillian can connect to this envir-
onment and run your integration tests. These are just some of the reasons you may choose
to use Arquillian. Let's assume ActionBazaar made this choice and wants to perform its
integration testing using Arquillian. First, we'll look at how to set up the project to use Ar-
15.4.1. Project configuration
The code for this chapter contains a Maven submodule named chapter15-ejb-
arquillian-test . This project contains the Arquillian integration tests for the
As discussed in the previous section on integration testing with the embedded EJBCon-
tainer , you need to decide where the integration test code will live. The Arquillian in-
tegration tests will be in their own external project for the same reasons that the embedded
EJBContainer integration tests are put in their own project. Integration tests are typic-
ally more complex, require external resources, and take much longer to run than unit tests.
So it's best practice to put the Arquillian integration tests in their own project. A continuous
integration testing tool, such as Bamboo or Jenkins, can be configured to run the integra-
tion test in case the development team forgets to do so before code changes are committed.
Configuring the project to run Arquillian integration tests is similar to the configuration
for the embedded EJBContainer integration tests. Maven, Arquillian, GlassFish, and
Derby all need to be configured to run the tests. You'll be using Arquillian's shrink-wrap
over the GlassFish implementation of the embedded EJBContainer , which is why you
still need to configure GlassFish. Before you do that, let's dive into the Maven configura-