One of the biggest challenges with testing is configuring the code to test. You may need to:

• swap in mock objects to enable the code to function,
• reconfigure the application to use a test database,
• deal with classpath isolation issues or
• run a build to assemble and deploy the application archive.

These steps are time consuming. ShrinkWrap to the rescue!

ShrinkWrap allows you to skip the build and instead define a deployment archive (jar, war, ear) declaratively in Java code. You define an archive inside your test case, termed a "micro deployment", and Arquillian deploys it to the container prior to executing the test case. Only those classes and resources in the archive are visible to the test case.

This strategy gives you tremendous control over the code you're testing and fast turnaround.

Arquillian enriches the test class with services such as:

• injection
• contexts
• interceptors

These services provide easy access to components under test and allows the test to abstract away plumbing, such as a transaction boundaries.

Here are some of the injection types that Arquillian supports in Java EE environments:

• @Inject (supported in any CDI environment)
• @Resource
• @EJB
• @PersistenceUnit / @PersistenceContext

Arquillian provides an SPI that allows you to introduce additional enrichment to this list.

The test class does not reference the container directly. That means you can run the same test case against various containers and you don't get locked into a proprietary test environment. It also means you can select the optimal container for development or easily test the compatibility of your application.

Arquillian recognizes three container interaction styles:

• A remote container resides in a separate JVM from the test runner. Arquillian binds to the container to deploy the test archive and invokes tests via a remote protocol (e.g., Servlet).
• A managed container is the same as a remote container, but its lifecycle (startup/shutdown) is also managed by Arquillian.
• An embedded container resides in the same JVM and is mostly likely managed by Arquillian. No need to fiddle with Maven plugins!

A container is further classified by its capabilities:

• Java EE application server (e.g., JBoss AS, GlassFish)
• Servlet container (e.g., Tomcat, Jetty)
• standalone bean container (e.g., OpenEJB, Weld SE)
• OSGi container

Arquillian provides an SPI that allows you to introduce any additional container to this list.

Each Arquillian test can control its own run mode, of which there are two:

• in-container (in-process invocation)
• client (through a remote client)

In the first mode, Arquillian puts the test class inside the container alongside the components under test. Then, the test directly invokes the methods of the component instance that Arquillian injects.

Arquillian also supports deploying the application code separately to allow the test to act as a remote client to the deployed archive.

You can also mix and match these modes to cover a myriad of testing scenarios.

The Arquillian project uses the JBoss issue tracker and project management tool to organize and prioritize tasks.

Arquillian Issue Tracker | Open Issues | Roadmap

Arquillian is part of the JBoss Testing initiative, which is an effort to unify the testing-related projects to provide a comprehensive testing tool set for application developers.

The projects involved so far are:

• Arquillian
• ShrinkWrap
• JSFUnit
• Ajocado

The initiative brings together developers in the JBoss Community who are passionate about testing. You can find us on the #jbosstesting channel on Freenode IRC.

Arquillian originated as the JBoss Test Harness - created by Pete Muir as the foundation of the JSR-299 (CDI) and JSR-303 (Bean Validation TCKs). This work established the guiding principles of Arquillain - that the tests should be reusable in any container (because executing tests in a full Java EE container is expensive), that it was essential tests could be easily run easily from an IDE (to make debugging easy), and that the framework needed to build on existing test harnesses to allow reuse of existing tools.

The JBoss Test Harness prototyped a solution that provided:

1. Declarative, annotation driven assembly of archives - needed to allow easy execution from the IDE, without having to call out to a slow and cumbersome build script. In Arquillian this was replaced by ShrinkWrap, a fluent Java API for assembling archives such as JARs, WARs and EARs in Arquillian.
2. A Java Adapter API which could start/stop a container and deploy a test. This was needed to allow running inside an IDE, and also allow a test to be reused in multiple environments
3. Easy switching between incontainer and standalone mode. Arquillian demoted this concept, and instead treats incontainer and standalone tests as different types of containers
4. Packaging of the test case alongside the archive you deploy and delegating to TestNG to perform test execution, both in and out of the container
5. A pluggable test executor, allowing the framework to select incontainer execution or standalone execution for the same test

It quickly became obvious that this was something that could be really useful to other people outside of the CDI TCK and Bean Validation TCKs. As Pete had hacked the JBoss Test Harness together in 3 weeks, it was obviously better to take just the ideas and start afresh. At the time, work on Java EE 6 was reaching a crucial point, so this project was put on the backburner until late-2009, when Aslak popped up and quickly picked up the key ideas creating a clean, pluggable architecture, added JUnit support and test enrichment. Obviously we had to hire him!

Since then, support has been added for additional containers, more sophisticated test enrichment and other test framework integrations. Arquillian was put to use immediately as the foundation of the test suites in the Seam 3 modules and examples.

The artwork for the project was created by Cheyenne Weaver over many long months of creative deliberation with the project team.

The project name may or may not be related to the alien species from a popular movie about protecting the Earth from alien scum. We just want to protect you from infrastructure scum in your integration tests.