JBoss Community Archive (Read Only)

Arquillian

Containers

Arquillian's forte is not only its ease of use, but also its extensibility. Good integration testing is not just about testing in any environment, but rather testing in the environment of your application targets. It's easy to give ourselves false assurance by validating components in a specialized testing container, or by using mocks, only to realize that small variations and assumptions cause the components fail when the application is deployed to production. To make tests count, you want to execute them in the target environment, or container.

So what is the container Arquillian uses? Is it some proprietary testing container that emulates the behavior of the technology (Java EE)? Nope! It's pluggable. It can be your target runtime, such as JBoss AS, GlassFish or Tomcat. Or it can even been an embedded container such as OpenEJB, GlassFish Embedded or Weld SE. You can even use one container for development and another for continuous integration.

This portability is made possible by a RPC-style (or local, if applicable) communication between the test runner and the container, a real container. You can run the same test case against various containers and you don't get locked into a proprietary test environment.

Arquillian recognizes three container interaction styles:

A container is further classified by its capabilities:

Arquillian can control a variety of containers out of the box. If the container you are using isn't supported, Arquillian provides an SPI that allows you to introduce any additional container to the default collection.

JBoss.org Content Archive (Read Only), exported from JBoss Community Documentation Editor at 2020-03-10 09:40:12 UTC, last content change 2012-04-07 19:42:27 UTC.