Arquillian / Arquillian tutorials

A test fixture a.k.a test context, represents the state of a component/application under test which is used as a baseline for running tests.

It may also refer to the actions performed before running any tests such as establishing database connection etc.

• Loading a database with sample data for testing.
• Preparation of input and setup mock objects.

POJO : plain old java object.

DOJO : http://dojotoolkit.org/ A javascript ajax framework and nothing to do with java or POJO.

A Java bean is compliant to certain conventions- Getter/setter naming, having a public default constructor, being serializable etc.

POJO is an acronym for Plain Old Java Object. The name is used to emphasize that a given object is an ordinary Java Object, not a special object

A POJO is a Java object that doesn't have a convention/rules to implement a particular interface or derive from a particular base class, or make use of particular annotations in order to be compatible with a given framework, and can be any arbitrary (often relatively simple) Java object.

POJO tests look similar to JUnit or TestNG tests, though they do not require any dependencies.

A test class should be named **/*Test and should contain test* methods.

Validating assertions can be done using the JDK 1.4 assert keyword.

Parallel test execution is not possible with POJO tests.

Fixtures can be setup before and after each test* method by implementing a set-up and a tear-down methods. These methods must match the exact signature and executed before and after each test method.

public void setUp();

public void tearDown();

Yes, we need to add JUnit 4.8, the minimum required version of JUnit to use Arquillian, as a test-scoped dependency.

• @RunWith(Arquillian.class) annotation required on the Test class.
• A public static method annotated with @Deployment that returns a ShrinkWrap archive.
• At least one method annotated with @Test.

@RunWith instructs JUnit or other test providers to use Arquillian as the test controller.

public static method annotated with the @Deployment annotation faciliates Arquillian to retrieve the test archive.

Each @Test method runs inside the container environment.

Please note that @Deployment method is optional and it is required only for the tests that runs inside the container.Client-side tests doesn't require a test archive so @Deployment method is optional.

Test archive isolates the classes and resources which are needed by the test from the remainder of the classpath. Arquillian includes the classes and resources that the test needs.

Test archive is created/defined by ShrinkWrap API.

Test archive helps create lean and manageable tests.

To execute the Arquillian test, we need to add a container adapter to the class path and run the test similar to how Junit test is run.

A container adapter controls and communicates with a container.

container adapter available on the test class path decides which target container(e.g., Weld Embedded, JBoss AS, GlassFish) to be used.

An Arquillian test can be executed in any container that is compatible with the programming model used in the test given that target container has Arquillian (container) Adapter.

The difference lies on how the server container is managed and the JVM used to execute test cases.

Embedded container: Arquillian manages the container, start it up before the test execution and shutdown after the tests are complete. Container runs on the same JVM as your test case.

Managed container: Arquillian manages the container, start it up before the test execution and shutdown after the tests are complete. However container runs on a different JVM than your test case.

Remote container: Arquillian assumes the container is up and running already, will push the deployment to the container and have the tests run.