Mission statement draft

[dan.j.allen]

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

[aslak]

Excellent..

Should we add something about Arquillian trying to be/behave like what you test? (@EJB/@Inject etc)

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.

It might make it a bit harder to explain, but we're not really limited to the EE platform. Guice is mentioned in the examples part..

using existing IDE, And and Maven test plugins without any additional plugins.

I presume you mean Ant. .

[dan.j.allen]

Should we add something about Arquillian trying to be/behave like what you test? (@EJB/@Inject etc)

I'll try to squeeze something in there.

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.

It might make it a bit harder to explain, but we're not really limited to the EE platform. Guice is mentioned in the examples part..

When I say "Java enterprise", to me that is not the same as the Java EE platform. To me, Java enterprise means that you are developing applications which are not Java desktop applications, rather for the web. I guess you could argue that Arquillian could even test desktop application code. So perhaps I'll just leave it at Java applications.

[dan.j.allen]

Updated version:

The mission of the Arquillian project is to provide a simple mechanism to develop a wide range of integration-style tests for Java applications (most likely enterprise applications).

An Arqullian test case may either be run inside the container (in situ) or interact as a client of the application. Inside the container, the test case can hook into the application using annotations like @Inject and @EJB. 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). 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.

[dan.j.allen]

With some formatting applied:

The mission of the Arquillian project is to provide a simple mechanism to develop a wide range of integration-style tests for Java applications (most likely enterprise applications). A test case may be run inside the container (in situ) or act as a client to validate the application's behavior. Inside the container, a test case can hook into the application using annotations like @Inject and @EJB.

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). The important part is that the environment used by tests is pluggable, so the developer is not locked into some proprietary testing container.

Arquillian will make integration testing a breeze.

[dan.j.allen]

Here's the abbreviated mission statement.

Arquillian provides a easy mechanism to test your application code inside a container (remote or embedded) or by interacting as a client.

Perhaps this should go to two paragraphs?

[pmuir]

Dan, great work.

No one seems to have any objections, so I think this should now be a closed issue :-)