11 June 2018

In a previous post I have described how easy it has become to use Arquillian via the Chameleon extension. The only "complex" part that’s left is the @Deployment-annotated method specificing the deployment via Shrinkwrap.

What exists for this is the @MavenBuild-annotation. It allows to trigger a maven-build and use the generated artifact. Usually, this would be the regularly built EAR or WAR-file as the deployment; which is fine in a lot of situations. Unfortunately, there is no @GradleBuild-annotation today. But there is the @File-annotation to just reference any EAR or WAR on the filesystem; assuming it was previously built by the Gradle-build, we can just reference the artifact.

@ChameleonTarget(value = "wildfly:11.0.0.Final:managed")
public class HelloServiceIT {

    private HelloService service;

    public void shouldGreetTheWorld() throws Exception {
        Assert.assertEquals("hello", service.hello());

Note that there is no @Deployment-annotated method. The build/libs/hello.war is built with the normal Gradle build task. If we set up our integrationTest-task like this, we can require the build-task as a dependency:

test {
    // Do not run integration-tests having suffix 'IT'
    include '**/*Test.class'

dependencies {
    testCompile 'org.arquillian.container:arquillian-chameleon-junit-container-starter:1.0.0.CR2'
    testCompile 'org.arquillian.container:arquillian-chameleon-file-deployment:1.0.0.CR2'

task integrationTest(type: Test) {
    group 'verification'
    description 'Run integration-tests'
    dependsOn 'build'
    include '**/*IT.class'

Run it with gradle integrationTest.

If you are wondering what other containers are supported and can be provided via the @ChameleonTarget-annotation, see here for the list. The actual config of supported containers is located in a file called containers.yaml.


The only disadvantage right now is that it will only work as expected when running a full gradle integrationTest. If you are e.g. in Eclipse and trigger a single test, it will simply use the already existing artifact instead of creating/building it again. This is what @MavenBuild is doing; and I hope we will get the equivalent @GradleBuild as well soon.