Home » Java » Enterprise Java » Arquillian Chameleon. Simplifying your Arquillian tests

About Alex Soto

Alex Soto

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

@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, 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 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 multimodule project, you don’t want to run the build from module where 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 as client.

You can see full example at: https://github.com/lordofthejars/games-monolith/blob/master/gamepage/impl/src/test/java/org/lordofthejars/games/game/GameResourceRestApiTest.java

Also you can read more about autodeployment feature at https://github.com/arquillian/arquillian-core/blob/master/docs/deployment-archives.adoc#deployment-archives-using-java-spi

Conclusions

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

We keep learning,

Alex

Published on Java Code Geeks with permission by Alex Soto, partner at our JCG program. See the original article here: Arquillian Chameleon. Simplifying your Arquillian tests

Opinions expressed by Java Code Geeks contributors are their own.

(+1 rating, 1 votes)
You need to be a registered member to rate this.
Start the discussion Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments