One of the core steps in every continuous integration process is running integration tests for your application. Unlike vanilla unit tests, integration tests allow you to assess the state of your applications or systems by testing all of its components together (modules, databases, messaging, etc.) and verifying that they work correctly as a whole unit. Needless to say, integration tests are more complex that simple unit tests, have a larger footprint, take more time and are usually saved to test full releases or major changes to implementations.
Usually, when testing Java EE applications, there is a need to configure and start an instance of your preferred application server, run the tests against this running instance and when finished, clear everything up. In some cases it may be needed to prepare a separate running instance for each test, making the whole process CPU intensive, expensive and cumbersome to automate. That was usually the case until Arquillian came along.
Simpler Integration Tests with Arquillian
Arquillian came along to simplify the process of running full integration tests suites for Java EE applications, by managing the lifecycle of your application servers or containers, bundling the test case along necessary resources into a test archive, providing dependency injection providers to the test cases to simplify the test writing and more. In addition, Arquillian supports both JUnit and TestNG so writing tests with it shouldn't be a problem. This is done thanks to the concept of container adapters, which Arquillian uses to connect and manage a profile of an specific application server's container (like GlassFish or WildFly). If you are developing application that you want to test for an specific container, simply use the corresponding container adapter on your integration tests. There are 3 types of container adapters for application servers:
- Embedded
Manages the lifecycle of an embedded container (runs in the same JVM as the test runner). Embedded containers are usually composed of APIs and its implementations without any added features present in the application server like monitoring or administration. Embedded containers are usually opted for faster test suites due to their simplicity of management.
- Managed
Manages the lifecycle of a local installation of the container/server. This means that the full application server is used to run the tests, so this might impact on the footprint of the suite, including the time to start/stop the container.
- Remote
The adapter itself doesn't manage the lifecycle of a container but binds to an already running container, either locally or on a remote location. This can simplify tests in many scenarios when the continuous integration workflow depends on an already configured application server's instance since the tests only need to know where the server's is located and Arquillian manages the communication to it.
Payara Server & Arquillian
Payara Server has, until now, not been officially supported in the list of available container adapters that Arquillian provides to developers. As a workaround, when writing integration tests for Payara Server in mind, it was officially recommended to use the official Glassfish 3.1 Arquillian Container adapter to let integration tests communicate with Payara Server (since Payara Server is derived from GlassFish, there's a degree of compatibility between them). If you are using Maven to handle your application testing, you only need to add the following dependency to use the embedded mode adapter for GlassFish 3.1:
<dependency>
<groupId>org.jboss.arquillian.container</groupId>
<artifactId>arquillian-glassfish-embedded-3.1</artifactId>
<version>1.0.1</version>
<scope>test</scope>
</dependency>
There are some problems with depending on this container adapter, mainly that is for communicating with either commercial or open source GlassFish server 3.1, which is compatible with Java EE 6. Considering that Payara Server is derived from GlassFish 4.1 which is compatible with Java EE 7, this means that you won't be able to test features or APIs introduced in Java EE 7. For this reason alone, starting with release 4.1.2.173, we have developed a special container adapter with the following Maven coordinates:
<dependency>
<groupId>fish.payara.arquillian</groupId>
<artifactId>arquillian-payara-server-4-embedded</artifactId>
<version>1.0.Beta2</version>
<scope>test</scope>
</dependency>
And that's it! To use the managed and remote adapters, change the artifactId to either arquillian-payara-server-4-managed or arquillian-payara-server-4-remote instead.
When running an integration test suite using this adapter, you should see no difference when running them using the adapter for GlassFish 3.1, with the exception of updated output values for the libraries and changes made for Payara Server 4.x
Also, remember to add the payara-embedded-all or payara-embedded-web dependencies to your project as well. Specify the exact version of the intended Payara Server this way:
<dependency>
<groupId>fish.payara.extras</groupId>
<artifactId>payara-embedded-all</artifactId>
<version>4.1.2.173</version>
<scope>test</scope>
</dependency>
Summary
With this official container adapter, Payara Server now has full integration with the Arquillian environment, bringing the following benefits:
- Allow Payara Server integration tests to be run in a continuous integration setup with 100% reliability
- Prepare the groundwork for a Payara 5 container adapter, which should allow users the ability to test Java EE 8 APIs
- Provide means to test specific Payara features (Hazelcast persistence, JCache, etc.)
With this in mind, we recommend you to start using the new Arquillian adapter to run your integration tests - and once you do, please make sure you give us your feedback!
