Arquillian Chameleon - Simplifying Your Arquillian Tests

Arquillian Chameleon was born to simplify the configuration of Arquillian tests. I am proud to announce that with version 1.0.0.CR2 we have not only simplified how to configure Arquillian tests but also how to write them.

With this new release, three new simplifications have been added:

• You only need to use 1 (or at most 2 dependencies just in case you want to use auto-deployment feature).
• It is not necessary to add any dependency to define which application server you want to use to run tests. Even not necessary to use arquillian.xml file to define it.
• It is not necessary to use ShrinkWrap to build your package. You can still use it, but you can delegate the process of creating the package to a custom SPI.

So let's start.

Dependency

You only need to add one dependency you don't need to add Arquillian dependency + container dependency anymore.

 <dependency>
        <groupId>org.arquillian.container</groupId>
        <artifactId>arquillian-chameleon-junit-container-starter</artifactId>
        <version>${arquillian.chameleon.version}</version>
        <scope>test</scope>
</dependency>

Definition of Container

Now to define a container you just need to use a special runner and special annotation:

@RunWith(ArquillianChameleon.class)
@ChameleonTarget("wildfly:11.0.0.Final:managed")
public class GameResourceRestApiTest {
}

You just need to use ArquillianChameleon runner and the special annotation @ChameleonTarget to define which container you want to use. In this example, Wildfly 11 with the managed mode is configured.

When running this test, the classpath is going to be configured with Arquillian Wildfly dependency, download the application server and behave as any other Arquillian test.

You can learn more about this feature at https://github.com/arquillian/arquillian-container-chameleon#arquillian-chameleon-runner.

AutoDeployment

Arquillan allows you to define a Java SPI to describe how the archive should be created. This effectively means that no @Deployment method is required if you provide an implementation which automatically creates the deployment file.

Arquillian Chameleon provides, at this time, two implementations:

1. File, which deploys an already created file. You need to set the location of the file.
2. Maven which runs using embedded Maven the build of the project and the generated archive is used as deployment archive.

For this example, I am going to use a multi-module project as an example, but notice that if you create a none multimodule project, then defaults works perfectly.

<dependency>
        <groupId>org.arquillian.container</groupId>
        <artifactId>arquillian-chameleon-maven-build-deployment</artifactId>
        <version>${arquillian.chameleon.version}</version>
        <scope>test</scope>
</dependency>

@RunWith(ArquillianChameleon.class)
@ChameleonTarget("wildfly:11.0.0.Final:managed")
@MavenBuild(pom = "../../pom.xml", module = "gamepage/impl")
@DeploymentParameters(testable = false)
public class GameResourceRestApiTest {

    @ArquillianResource
    URL url;
}

Notice that depending on the method you choose (File or Maven) you need to add the implementation on the classpath.

In this case, I choose to use the Maven approach which means that the archive is generated by building all project.

Two things that are specific to this test and needs to be customized (instead of defaults) because of the example.

First one is the pom location. By default, the @MavenBuild annotation uses the pom.xml where the test is executed. In case of multi-module project, you don't want to run the build from module where a test is defined but from the root of the project, so you get a complete archive with all dependencies. For this case, you need to set it where is located.

The second one is where is the archive generated to be used to deploy. By default, you don't need to specify anything since in case of none multimodule project you are only generating one file. But in case of multimodule projects, you are generating multiple archives, so you need to specify which module contains the final archive.

And that's all, when you run this test, Arquillian will download Wildfly, start it, runs the build to get the final deployment file (such as .war), deploy it and finally run the test.

Notice that also there is @DeploymentParameters annotation which is not mandatory to be used, but allows you to configure the deployment as you do with @Deployment annotation, such as setting a deployment name or changing the mode from a container (the default one) to a client.

You can see full example here.

Also, you can read more about the autodeployment feature here.

Conclusions

You can see that everything has been simplified a lot. The idea is to offer a similar experience that you get when running Spring tests.

Keep learning,

Alex