In the last years Apache Maven has become the de-facto build tool for Java and Java EE projects. But from two years back Gradle is gaining more and more users. Following my previous post (http://www.lordofthejars.com/2015/10/gradle-and-java-ee.html), In this post you are going to see how to use Gradle for writing integration tests for Java EE using Arquillian.
Gradle is a build automation tool like Ant or Maven but introducing a Groovy-based DSL language instead of XML. So as you might expect the build file is a Groovy file. You can read in my previous post (http://www.lordofthejars.com/2015/10/gradle-and-java-ee.html) how to install Gradle.
To write integration tests for Java EE, the de-facto tool is Arquillan. If you want to know what Arquillian is, you can get a Getting Start Guide in (http://arquillian.org/guides/getting_started/) or in book Arquillian In Action.
To start using Arquillian, you need to add Arquillian dependencies, which comes in form of BOM. Gradle does not support BOM artefacts out of the box, but you can use dependency-management-plugin Gradle plugin to have support to define BOMs.
To start using Arquillian, you need to add Arquillian dependencies, which comes in form of BOM. Gradle does not support BOM artefacts out of the box, but you can use dependency-management-plugin Gradle plugin to have support to define BOMs.
Moreover Gradle offers the possibility to add more test source sets apart from the default one which as in Maven is src/test/java and src/test/resources. The idea is that you can define a new test source set where you are going to put all integration tests. With this approach each kind of tests are clearly separated into different source sets. You can write Groovy code in Gradle script to achieve this or you can just use gradle-testsets-plugin which it is the easiest way to proceed.
So to register both plugins (dependency and testsets) you need to add next elements in build.gradle script file:
buildscript {
repositories {
jcenter()
}
dependencies {
classpath "io.spring.gradle:dependency-management-plugin:0.5.3.RELEASE"
classpath 'org.unbroken-dome.gradle-plugins:gradle-testsets-plugin:1.2.0'
}
}
apply plugin: "io.spring.dependency-management"
apply plugin: 'org.unbroken-dome.test-sets'
Now it is time to add Arquillian dependencies. You need to add the Arquillian BOM, and two dependencies, one that sets that we are going to use Arquillian with JUnit, and another one that sets Apache TomEE application server as target for deploying the application during test runs.
build.gradle with Arquillian, TomEE and Java EE dependency might look like:
dependencyManagement {
imports {
mavenBom 'org.arquillian:arquillian-universe:1.0.0.Alpha1'
}
}
dependencies {
testCompile group: 'org.arquillian.universe', name: 'arquillian-junit', ext: 'pom'
testCompile group: 'org.apache.openejb', name: 'arquillian-tomee-embedded', version:'1.7.2'
testCompile group: 'junit', name: 'junit', version:'4.12'
providedCompile group: 'org.apache.openejb',name: 'javaee-api', version:'6.0-6'
}
Finally you can configure the new integration test folder as source set by adding next section:
testSets {
integrationTests
}
Where integrationTest is the name of the test set. testSets automatically creates and configures next elements:
- src/integrationTests/java and src/integrationTests/resources as valid source set folders.
- A dependency configuration named integrationTestsCompile which extends from testCompile, and another one called integrationTestRuntime which extends from testRuntime.
- A Test task named integrationTests which runs the tests in the set.
- A Jar task named integrationTestsJar which packages the tests.
Notice that you can change the integrationTests to any other value like intTests and Gradle would configure previous elements automatically to the value set it inside testSets, such as src/intTests/java or for example the test task would be called intTests.
Next step is creating the integration tests using Arquillian inside integrationTests test set. For example an Arquillian test for validating that you can POST a color in a REST API and it is returned when GET method is called, would look like:
You can now run integration tests by simply executing gradlew integrationTests
Next step is creating the integration tests using Arquillian inside integrationTests test set. For example an Arquillian test for validating that you can POST a color in a REST API and it is returned when GET method is called, would look like:
You can now run integration tests by simply executing gradlew integrationTests
You'll notice that if you run gradlew build, the integration test task is not run. This happens because task is not registered within the default build lifecycle. If you want to add integrationTests task to be executed automatically during build you need to add next lines:
check.dependsOn integrationTest
integrationTest.mustRunAfter test
Ensure that integration tests are run before the check task and that the check task fails the build if there are failing integration tests and also ensures that unit tests are run before integration tests. This guarantees that unit tests are run even if integration tests fails.
So now when you run gradlew build, the integration tests are going to be executed as well.
And finally, what's happen if you are running JaCoCo plugin for code coverage? You will get two JaCoCo files, one for the unit test executions and another one for the integrationTests execution. But probably you want to see an aggregated code coverage report of both runs into one file, so you can inspect the code coverage degree of the application after the execution of all kind of tests. To achieve it you only need to add next task:
task jacocoRootTestReport(type: JacocoReport) {
sourceSets sourceSets.main
executionData files([
"$buildDir/jacoco/test.exec",
"$buildDir/jacoco/integrationTests.exec"
])
reports {
xml.enabled false
csv.enabled false
}
}
In this case you are creating a task which aggregates the coverage results of test.exec file (which comes from unit tests) and integrationTests.exec which comes from integration tests.
And to generate the reports you need to explicitly call the jacocoRootTestReport task when you run Gradle.
So it is so simple to write a Gradle script for running Java EE tests and more important the final script file looks very compact and readable without being tight to any static convention at all.
We keep learning,
Alex.
Alex.
There must be more to life than this, There must be more to life than this, How do we cope in a world without love (There Must Be More To Life Than This - Freddie Mercury - Michael Jackson)
