Prev Next

Arquillian / Arquillian tutorials

Could not find what you were looking for? send us the question and we would be happy to answer your question.

1. Test Fixture.

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.

2. Example of fixtures.
  • Loading a database with sample data for testing.
  • Preparation of input and setup mock objects.
3. Differentiate POJO and DOJO.

POJO : plain old java object.

DOJO : A javascript ajax framework and nothing to do with java or POJO.

4. Difference between Java bean and 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.

5. POJO Tests.

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

6. Class & method name convention for POJO tests.

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

7. How the assertion validations are performed in POJO tests?

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

8. One of the disadvantages of using POJO tests.

Parallel test execution is not possible with POJO tests.

9. Fixture for 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();

10. Does Arquillian need JUnit?

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

11. The three requirements for creating an Arquillian test.
  • @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.

12. Test Archive.

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.

13. Executing your Arquillian test.

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.

14. Container Adapter.

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.

15. Differentiate embedded, managed and remote container in Arquillian.

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.

The Future of Automation Testing: Trends to Watch

Comments & Discussions