DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Securing Your Software Supply Chain with JFrog and Azure
Register Today

Trending

  • DZone's Article Submission Guidelines
  • Is Podman a Drop-In Replacement for Docker?
  • Effective Java Collection Framework: Best Practices and Tips
  • Microservices With Apache Camel and Quarkus

Trending

  • DZone's Article Submission Guidelines
  • Is Podman a Drop-In Replacement for Docker?
  • Effective Java Collection Framework: Best Practices and Tips
  • Microservices With Apache Camel and Quarkus

Arquillian Chameleon - Simplifying Your Arquillian Tests

Learn about Arquillian Chameleon, a tool made to simplify the configuration of Arquillian tests, including the auto-deployment feature.

Alex Soto user avatar by
Alex Soto
·
Mar. 28, 18 · Tutorial
Like (4)
Save
Tweet
Share
5.66K Views

Join the DZone community and get the full member experience.

Join For Free

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

Testing

Published at DZone with permission of Alex Soto, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • DZone's Article Submission Guidelines
  • Is Podman a Drop-In Replacement for Docker?
  • Effective Java Collection Framework: Best Practices and Tips
  • Microservices With Apache Camel and Quarkus

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: