The secret ingredient required to activate the Arquillian test runner is getting the correct libraries on the classpath. (Often easier said than done). The libraries consist of the Arquillian container integration and the container runtime (for an embedded container) or deployment client (for a remote container).

In general, the steps to incorporate Arquillian into a build, regardless of what build tool you are using, can be summarized as:

1. Activate/configure the JUnit or TestNG task/plugin

2. Add the Arquillian container integration to the test classpath (e.g., org.jboss.arquillian.container:arquillian-%VENDOR%-%TYPE%-%VERSION%)

3. Add the container runtime (embedded) or deployment client (remote) to the classpath

4. Execute the test build task/goal

If you are only running the Arquillian tests on a single container, this setup is exceptionally straightforward. The challenge comes when you want to run the tests on multiple containers. It's really just a matter of putting the correct libraries on the test classpath, though.

For some build systems, isolating multiple classpath definitions is more tricky than others. For instance, in Maven, you only get one test classpath per run (without using really advanced plugin configuration). You can toggle between different test classpath pairings through the use of profiles. Each profile contains the libraries for a single target container (a combination of the libraries itemized in steps 2 and 3 above). You'll see this strategy used in the Arquillian examples.

Other build tools, such as Gradle, can easily define new test tasks that each have their own, unique classpath. This makes it not only possible to separate out the target containers, but also run the tests against each one in the same build execution. We'll see an example of that later in this chapter. Gradle can also emulate the Maven profile strategy through the use of build fragment imports. We'll also show an example of that approach for contrast.