I've revised the Arquillian mission statement based on what was discussed in the Arquillian Design Kickoff. Let me know if you have any suggestions or revisions.
The mission of the Arquillian project is to provide a simple mechanism to develop a wide range of integration-style tests for Java enterprise applications. A test case may either be run inside the container (in situ) or interact as a client of the application. Arquillian seeks to minimize the burden on the developer to perform such integration testing by handling all aspects of the test execution, which may include controlling the lifecycle of the container (start/stop), bundling the test class, dependent classes and/or resources into a deployable archive, deploying the archive to test (deploy/undeploy) and capturing results and failures. To avoid introducing unnecessary complexity into the developer's build environment, Arquillian integrates transparently with familiar testing frameworks (e.g., JUnit 4, TestNG 5), allowing tests to be launched using existing IDE, Ant and Maven test plugins without any additional plugins.
The main benefit that Arquillian delivers is to allow tests to be executed in a container, or through coordination with a container. There are two styles of container, remote and embedded. A remote container resides in a separate JVM from the test runner. Its lifecycle may be managed by Arquillian, or Arquillian may simply bind to a running container. An embedded container resides in the same JVM and is mostly likely managed by Arquillian. Any container can be further classified by its capabilities. Containers may be fully compliant Java EE application servers (e.g., GlassFish, JBoss AS, Embedded GlassFish), Servlet containers (e.g., Tomcat, Jetty) or bean containers (e.g., Weld SE, Guice). The important part is that the environment used by tests is pluggable, so the developer is not locked into some proprietary testing container.
Arquillian should make integration testing a breeze.
It's important that the mission capture the goals we want to accomplish while not shoehorning us into design limitations by making too many assumptions.
Message was edited by: Dan Allen