Running specific tests using gradle over multiple browsers - gradle

I'm using Geb/Spock for automated testing. I'm using Gradle as my build tool.
I'd like to call different gradle tasks to build and run a specific spec(test) or a suite of specs.
I dont know enough about the gradle build lifecycle to completely understand what is going on here: https://github.com/geb/geb-example-gradle/blob/master/build.gradle
plugins {
id "idea"
id "groovy"
id "com.energizedwork.webdriver-binaries" version "1.4"
id "com.energizedwork.idea-base" version "1.4"
}
ext {
// The drivers we want to use
drivers = ["firefox", "chrome", "chromeHeadless"]
ext {
groovyVersion = '2.4.12'
gebVersion = '2.2'
seleniumVersion = '3.6.0'
chromeDriverVersion = '2.32'
geckoDriverVersion = '0.18.0'
}
}
repositories {
mavenCentral()
}
dependencies {
// If using Spock, need to depend on geb-spock
testCompile "org.gebish:geb-spock:$gebVersion"
testCompile("org.spockframework:spock-core:1.1-groovy-2.4") {
exclude group: "org.codehaus.groovy"
}
testCompile "org.codehaus.groovy:groovy-all:$groovyVersion"
// If using JUnit, need to depend on geb-junit (3 or 4)
testCompile "org.gebish:geb-junit4:$gebVersion"
// Drivers
testCompile "org.seleniumhq.selenium:selenium-chrome-driver:$seleniumVersion"
testCompile "org.seleniumhq.selenium:selenium-firefox-driver:$seleniumVersion"
}
webdriverBinaries {
chromedriver chromeDriverVersion
geckodriver geckoDriverVersion
}
drivers.each { driver ->
task "${driver}Test"(type: Test) {
group JavaBasePlugin.VERIFICATION_GROUP
outputs.upToDateWhen { false } // Always run tests
systemProperty "geb.build.reportsDir", reporting.file("geb/$name")
systemProperty "geb.env", driver
}
}
test {
dependsOn drivers.collect { tasks["${it}Test"] }
enabled = false
}
tasks.withType(Test) {
maxHeapSize = "1g"
jvmArgs '-XX:MaxMetaspaceSize=128m'
testLogging {
exceptionFormat = 'full'
}
}
tasks.withType(GroovyCompile) {
groovyOptions.forkOptions.memoryMaximumSize = '256m'
}
I've tried inserting the following into build.gradle:
task dataGen {
include '**com.company.project.spec.util/DataGenerationUtilSpec.groovy'
}
task sanity {
include '**com.company.project.spec.sanity.*'
}
But calling these tasks (gradle sanity) results in a build failure:
Could not find method include() for arguments [**com.company.project.spec.util/DataGenerationUtilSpec.groovy] on task ':dataGen' of type org.gradle.api.DefaultTask
Obviously there's existing build instructions since I can call gradle build and all the specs run on Chrome, I'm just not sure how to add more tasks

I think these 2 tasks are test tasks so it should look like that :
task dataGen (type: Test) {
include '**com.company.project.spec.util/DataGenerationUtilSpec.groovy'
}
task sanity (type: Test) {
include '**com.company.project.spec.sanity.*'
}

You can use Spock annotation to control the test or the Spec, see example here.
You will have to define annotation classes and define the Spock config file to use that annotation. You then annotate the specific Specification (or test).
Now you will have to define the Spock config file in the task or from a parameter.

Related

How to run grails integration tests with gradle

Old internal-tools.gradle
description = 'Internal Tools'
ext {
grailsVersion = "2.4.4"
}
apply plugin: "grails"
grails {
grailsVersion = "2.4.4"
springLoadedVersion = '1.2.4.RELEASE'
}
configurations.all {
// already provided by the JVM, Grails complains if classes show up twice in the classpath
exclude group: 'xml-apis', module: 'xml-apis'
exclude module: 'grails-plugin-log4j'
//provided servlet container
exclude group: 'javax.el', module: 'el-api'
exclude group: 'org.glassfish.web', module: 'el-impl'
}
dependencies {
compile project(':business-logic')
test(project(path: ':business-logic', configuration: 'testArtifacts'))
def slf4jVersion = '1.7.2'
compile "org.slf4j:jcl-over-slf4j:${slf4jVersion}"
compile "org.slf4j:jul-to-slf4j:${slf4jVersion}"
compile "org.slf4j:slf4j-api:${slf4jVersion}"
// We force a newer version of Ant to work around a bug in the Oracle JRE. This can be removed when Grails upgrades Ant
// See Ant 'Bug 54641' for more details
runtime "org.apache.ant:ant:1.9.2"
runtime "org.apache.ant:ant-junit:1.9.2"
// Grails
runtime "org.grails:grails-dependencies:$grailsVersion"
// Grails plugins
compile "org.grails.plugins:hibernate4:4.3.6.1"
compile "org.grails.plugins:tomcat:7.0.55"
compile "org.grails.plugins:export:1.6"
compile "org.grails.plugins:webflow:2.1.0"
compile 'org.grails.plugins:logback:0.3.1'
runtime "org.grails:grails-plugin-validation:$grailsVersion"
test "org.grails:grails-test:$grailsVersion"
test "org.grails:grails-plugin-testing:$grailsVersion"
test 'org.hamcrest:hamcrest-all:1.1'
test 'org.mockito:mockito-all:1.8.0'
test 'nekohtml:nekohtml:1.9.6.2'
bootstrap 'ch.qos.logback:logback-classic:1.1.3'
}
test {
doFirst {
tasks.getByPath(':dbTestCreate').ext.testDatabase.create()
}
dependsOn(':configProperties')
jvmOptions.jvmArgs '-XX:MaxMetaspaceSize=256m'
jvmOptions.systemProperty('XXXX.conf.file', "$configOutputDir/XXXX_test.properties")
String protocol = "file:"
jvmOptions.systemProperty 'logback.configurationFile', protocol + new File(rootProject.projectDir,"dev/log/logback.xml").getAbsolutePath()
}
'grails-run-app' {
dependsOn(':configProperties', ':dbValidate')
jvmOptions.jvmArgs '-XX:MaxMetaspaceSize=256m'
jvmOptions.systemProperty('XXXX.conf.file', "$configOutputDir/XXXX_dev.properties")
String protocol = "file:"
jvmOptions.systemProperty 'logback.configurationFile', protocol + new File(rootProject.projectDir,"dev/log/logback.xml").getAbsolutePath()
}
war {
String protocol = "file:"
jvmOptions.systemProperty 'logback.configurationFile', protocol + new File(rootProject.projectDir,"dev/log/logback.xml").getAbsolutePath()
}
// We re-package the war so it will include the extra GradleCM meta-info.
// We use a zip task rather than a war task because the war task adds extra files such as a second web.xml
task reWar(type: Zip, dependsOn: ['war']) {
destinationDir = file("$buildDir/libs")
extension = 'war'
// HACK: the input needs to be wrapped in a closure so it is evaluated lazily. This is because the 'war' task output
// file changes once the version is set
from { zipTree(war.outputFile) }
//
// Build info file
//
from (rootProject.buildinfo.filedir) {
include rootProject.buildinfo.filename
into 'META-INF'
}
}
artifacts {
archives reWar
}
// Ensure tests are run for uploadArchives
uploadArchives.dependsOn('check')
buildscript {
repositories {
maven {
url "http://nexus.XXXXX.com/content/groups/public/"
}
}
dependencies {
classpath "org.grails:grails-gradle-plugin:2.1.2"
}
}
New internal-tools.gradle
description = 'Internal Tools'
ext {
grailsVersion = "3.3.3"
}
apply plugin: "org.grails.grails-web"
apply plugin: "war"
apply plugin:"org.grails.grails-gsp"
grails {
grailsVersion = "3.3.3"
//springLoadedVersion = '1.2.4.RELEASE'
}
configurations.all {
// already provided by the JVM, Grails complains if classes show up twice in the classpath
exclude group: 'xml-apis', module: 'xml-apis'
exclude module: 'grails-plugin-log4j'
//provided servlet container
exclude group: 'javax.el', module: 'el-api'
exclude group: 'org.glassfish.web', module: 'el-impl'
}
dependencies {
compile project(':business-logic')
//test(project(path: ':business-logic', configuration: 'testArtifacts'))
def slf4jVersion = '1.7.2'
compile "org.slf4j:jcl-over-slf4j:${slf4jVersion}"
compile "org.slf4j:jul-to-slf4j:${slf4jVersion}"
compile "org.slf4j:slf4j-api:${slf4jVersion}"
// We force a newer version of Ant to work around a bug in the Oracle JRE. This can be removed when Grails upgrades Ant
// See Ant 'Bug 54641' for more details
runtime "org.apache.ant:ant:1.9.2"
runtime "org.apache.ant:ant-junit:1.9.2"
// Grails
runtime "org.grails:grails-dependencies:$grailsVersion"
compile "org.grails:grails-plugin-validation:3.3.3"
compile 'org.grails.plugins:converters:4.0.0'
compile 'org.grails.plugins:gorm-tools:6.1.11-v.12'
compile "org.grails:grails-plugin-databinding"
compile "org.springframework.boot:spring-boot-starter-logging"
compile "org.springframework.boot:spring-boot-autoconfigure"
compile "org.springframework.boot:spring-boot-starter-actuator"
compile "org.springframework.boot:spring-boot-starter-tomcat"
compile "org.grails:grails-web-boot"
compile "org.grails:grails-core"
// Grails plugins
compile "org.grails.plugins:hibernate4:4.3.6.1"
compile "org.grails.plugins:tomcat:7.0.55"
compile "org.grails.plugins:export:1.6"
compile "org.grails.plugins:webflow:2.1.0"
compile 'org.grails.plugins:logback:0.3.1'
runtime "org.grails:grails-plugin-validation:$grailsVersion"
//test "org.grails:grails-test:$grailsVersion"
// test "org.grails:grails-plugin-testing:$grailsVersion"
// test 'org.hamcrest:hamcrest-all:1.1'
//test 'org.mockito:mockito-all:1.8.0'
// test 'nekohtml:nekohtml:1.9.6.2'
// bootstrap 'ch.qos.logback:logback-classic:1.1.3'
}
test {
doFirst {
tasks.getByPath(':dbTestCreate').ext.testDatabase.create()
}
dependsOn(':configProperties')
jvmArgs '-XX:MaxMetaspaceSize=256m'
systemProperty 'XXXX.conf.file', "$configOutputDir/XXXX_test.properties"
String protocol = "file:"
systemProperty 'logback.configurationFile', protocol + new File(rootProject.projectDir,"dev/log/logback.xml").getAbsolutePath()
}
bootRun {
dependsOn(':configProperties', ':dbValidate')
jvmArgs '-XX:MaxMetaspaceSize=256m'
systemProperty 'XXXX.conf.file', "$configOutputDir/XXXX_dev.properties"
String protocol = "file:"
systemProperty 'logback.configurationFile', protocol + new File(rootProject.projectDir,"dev/log/logback.xml").getAbsolutePath()
}
war {
String protocol = "file:"
//systemProperty 'logback.configurationFile', protocol + new File(rootProject.projectDir,"dev/log/logback.xml").getAbsolutePath()
}
// We re-package the war so it will include the extra GradleCM meta-info.
// We use a zip task rather than a war task because the war task adds extra files such as a second web.xml
task reWar(type: Zip, dependsOn: ['war']) {
destinationDir = file("$buildDir/libs")
extension = 'war'
// HACK: the input needs to be wrapped in a closure so it is evaluated lazily. This is because the 'war' task output
// file changes once the version is set
from { zipTree(war.archivePath) }
//
// Build info file
//
from (rootProject.buildinfo.filedir) {
include rootProject.buildinfo.filename
into 'META-INF'
}
}
artifacts {
archives reWar
}
// Ensure tests are run for uploadArchives
uploadArchives.dependsOn('check')
buildscript {
repositories {
maven { url "https://repo1.maven.org/maven2/" }
maven { url "https://dl.bintray.com/jfrog/jfrog-jars/" }
maven { url "https://repo.gradle.org/gradle/libs-releases-local/" }
//maven { url "https://repo.spring.io/plugins-release/" }
maven { url "https://repo.maven.apache.org/maven2/" }
maven { url "https://repo.grails.org/grails/core" }
mavenCentral()
}
dependencies {
classpath "org.grails:grails-gradle-plugin:3.3.3"
classpath "com.jfrog.bintray.gradle:gradle-bintray-plugin:1.+"
classpath "org.gradle:gradle-tooling-api:5.+"
classpath "org.codehaus.groovy.modules.http-builder:http-builder:0.7.+"
//classpath "org.grails.plugins:hibernate4:${gormVersion-".RELEASE"}"
}
}
I had to upgrade gradle from 2.2 to 3.5. One of the gradle modules I have is a grails app called internal-tools. I posted the old build.gradle we used and the new one I am still working on. I had to change some of it around after upgrading gradle to 3.5.
The old internal-tools.gradle used to start up the application and run through a series of integration tests. My new internal-tools.gradle is not starting up the application and running through the integration tests. I was wondering if anyone had any ideas or ran into the same problem upgrading gradle and grails. I inherited this project so I'm not 100% sure what these gradle files are doing.
If the 'grails-run-app' task is what started it up in the old gradle file what is the equivalent I can use in gradle 3.5? I tried putting the same things in a "bootRun" task but that doesn't seem to work. It could be related to an issue I was having where the app thought it was spring boot so I had to stick a public static void main in there so the ":internal-tools:findMainClass" would work.
Actually the more I look at it I think the grails-run-app was just used to start up the application after it was built. So I'm not sure what started up the application and ran the integration tests in the old gradle file, and how I can reproduce the same thing with gradle 3.5

Spring cloud contracts plugin change sourceset

I've started using Spring Cloud Contracts ('2.0.2.RELEASE') in my project and I have the following structure
src
|
-- main
-- test
-- integrationTest
-- contractTest
When I put my contracts and my base test class in test it was running fine. I want to move the contract tests that I have written into a separate sourceset, the contractTest sources. However, this will not work as the plugin generateContractTests task will still look in the test sourceset when trying to run.
I have made the following changes to my Gradle file
task contractTest(type: Test) {
description = 'Runs contract tests.'
group = 'verification'
testClassesDirs = sourceSets.contractTest.output.classesDirs
classpath = sourceSets.contractTest.runtimeClasspath
shouldRunAfter integrationTest
}
configurations {
contractTestImplementation.extendsFrom implementation
contractTestRuntimeOnly.extendsFrom runtimeOnly
}
sourceSets {
contractTest {
compileClasspath += sourceSets.main.output
runtimeClasspath += sourceSets.main.output
}
}
contracts {
// testFramework = 'JUNIT5'
packageWithBaseClasses = 'com.test.testapi.contracts'
contractsDslDir = new File("${project.rootDir}/src/contractTest/resources/contracts/")
}
contractTestImplementation 'org.codehaus.groovy:groovy-all:2.4.6'
contractTestImplementation 'org.springframework.cloud:spring-cloud-starter-contract-verifier'
contractTestImplementation group: 'org.junit.jupiter', name: 'junit-jupiter-api'
contractTestImplementation group: 'org.junit.jupiter', name: 'junit-jupiter-engine'
I think I need to set the contract plugin property contractDependency, however, I am not sure and can't find an example to get the plugin to work with this different sourceset
TLDR; I want to be able to run my contract tests in a different folder
UPDATE - I am not sure but I think that it is not possible as in the Gradle plugin in the "GenerateServerTestsTask.groovy" file has the following which would appear to signify that the sourceSet is hardcoded to test throughout the code
project.sourceSets.test.groovy {
project.logger.
info("Registering ${getConfigProperties().generatedTestSourcesDir} as test source directory")
srcDir getConfigProperties().getGeneratedTestSourcesDir()
}
For future reference, I was able to get it working by creating a custom task to deregister the generated sources from the test sourceset so that they wouldn't be compiled by compileTestJava and could be run via my own contractTests task.
sourceSets {
contractTest {
java {
compileClasspath += sourceSets.main.output + sourceSets.test.output
runtimeClasspath += sourceSets.main.output + sourceSets.test.output
srcDir file('src/contractTest/java')
srcDirs += file("${buildDir}/generated-contract-sources/")
}
resources.srcDir file('src/contractTest/resources')
}
}
task deregisterContractTestSources() {
doLast {
project.sourceSets.test.java {
project.logger.info('Removing any *Spec classes from the test sources')
exclude '**/*Spec*'
}
}
}
compileTestJava.dependsOn deregisterContractTestSources
task contractTests(type: Test) {
description = 'Runs contract tests'
group = 'verification'
testClassesDirs = sourceSets.contractTest.output.classesDirs
classpath = sourceSets.contractTest.runtimeClasspath
}
contracts {
baseClassForTests = 'com'
generatedTestSourcesDir = file("${buildDir}/generated-contract-sources")
generatedTestResourcesDir = file("${buildDir}/generated-contract-resources/")
testFramework = "JUNIT5"
contractsDslDir = new File("${projectDir}/src/contractTest/resources/contracts/")
nameSuffixForTests = 'Spec'
basePackageForTests = 'com'
}

Using testCompile output from other subproject (Gradle Kotlin DSL)

I have some utility files in the test sources in one of my gradle subproject and would like to use them in an other subproject.
My "source" subproject is called core, while the one uses it is called tem.
I try to migrate and integrate the following example:
In your Server project:
configurations {
testArtifacts.extendsFrom testCompile
}
task testJar(type: Jar) {
classifier "test"
from sourceSets.test.output
}
artifacts {
testArtifacts testJar
}
In your ServerWeb project:
testCompile project(path: ":Server", configuration: 'testArtifacts')
As far as I get is making the conversation. I added the following to my core.gradle.kts:
val testConfig = configurations.create("testArtifacts") {
extendsFrom(configurations["testCompile"])
}
tasks.register("testJar", Jar::class.java) {
classifier += "test"
from(sourceSets["test"].output)
}
artifacts {
add("testArtifacts", tasks.named<Jar>("testJar") )
}
And tried to refer to it in tem.gradle.kts:
testImplementation(project(":core", "testArtifacts"))
It compiles, but I still can't access the classes from core.
Where did I miss something?
Most of your code should be OK
But you must define classesDirs for jar
tasks.register<Jar>("testJar") {
dependsOn("testClasses")
archiveBaseName.set("${project.name}-test")
from(sourceSets["test"].output.classesDirs)
}
I also added depends on testClasses to be sure that classes are compiled.
You can test that jar is OK by executing testJar task. Then verify that generated jar contains your classes. If you make mistake with from method call then you get empty jar.
The following configuration worked for me to include both the test classes and test resources:
core build.gradle.kts
val testConfig = configurations.create("testArtifacts") {
extendsFrom(configurations["testCompile"])
}
tasks.register("testJar", Jar::class.java) {
dependsOn("testClasses")
classifier += "test"
from(sourceSets["test"].output)
}
artifacts {
add("testArtifacts", tasks.named<Jar>("testJar") )
}
tem build.gradle.kts
testImplementation(project(":core", "testArtifacts"))

Gatling running multiple simulations with Gradle plugin

The Gradle plugin (https://github.com/commercehub-oss/gatling-gradle-plugin, v2.1) claims The ability to configure multiple simulations per gradle project
Given the following gradle file:
apply plugin: 'scala'
group '****'
version '1.0-SNAPSHOT'
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.commercehub:gatling-gradle-plugin:2.1'
}
}
repositories {
jcenter()
}
ext {
SCALA_VERSION = "2.11.7"
GATLING_VERSION = "2.2.3"
}
dependencies {
compile "org.scala-lang:scala-library:${SCALA_VERSION}"
testCompile 'com.typesafe:config:1.3.1'
testCompile "io.gatling.highcharts:gatling-charts-highcharts:${GATLING_VERSION}"
testCompile "io.gatling:gatling-test-framework:${GATLING_VERSION}"
}
apply plugin: 'gatling'
import com.commercehub.gradle.plugin.GatlingTask
task loadTest(type: GatlingTask, dependsOn: ['testClasses']) {
gatlingSimulation = 'HealthSimulation,PlaceAttributesSimulation'
jvmOptions {
jvmArgs = [
"-Dlogback.configurationFile=${logbackGatlingConfig()}",
"-Denv=${System.getProperty('env', 'stg')}",
]
minHeapSize = "1024m"
maxHeapSize = "1024m"
}
}
def logbackGatlingConfig() {
return sourceSets.test.resources.find { it.name == 'logback-gatling.xml' }
}
in particular the line gatlingSimulation = 'HealthSimulation,PlaceAttributesSimulation', I would expect both simulation to be run. Why? Because looking at the Gradle plugin, gatlingSimulation is then passed to Gatling -s flag.
Long story short, Gatling -s does not support multiple simulations anymore (see https://github.com/gatling/gatling/issues/363 for details), so I think I am missing a bit in the gradle plugin I am using to enable multiple simulations.
Both simulations run fine when run individually, but if I try to run them together, Gatling stucks asking which one to execute. Any suggestion how to achieve running multiple simulations (sequentially) in the same gradle project?
EDIT: my currently ugly workaround (suggestions welcome to make it less ugly, but still workaround imo) is to modify the Gradle build file with:
task loadTests;
fileTree(dir: 'src/test').include("**/*Simulation.scala").each {target ->
ext {
filename = target.toString()
filename = filename.substring(filename.indexOf("scala") + "scala".length() + 1)
filename = filename.substring(0, filename.indexOf(".")).replaceAll("/", ".")
}
task("loadTest${filename}", type: GatlingTask, dependsOn: 'testClasses', description : "Load test ${filename}s") {
gatlingSimulation = filename
jvmOptions {
jvmArgs = [
"-Dlogback.configurationFile=${logbackGatlingConfig()}",
"-Denv=${System.getProperty('env', 'stg')}",
]
minHeapSize = "1024m"
maxHeapSize = "1024m"
}
}
loadTests.dependsOn("loadTest${filename}")
}
def logbackGatlingConfig() {
return sourceSets.test.resources.find { it.name == 'logback-gatling.xml' }
}
Basically, I create a GatlingTask for each *Simulation.scala file (naming convention) and then create a bulk loadTests task that depends on all.

JUnit5 tag-specific gradle task

I use the following annotation to tag my integration tests:
#Target({ ElementType.TYPE, ElementType.METHOD })
#Retention(RetentionPolicy.RUNTIME)
#Tag("integration-test")
public #interface IntegrationTest {
}
This is the filter I use in build.gradle to exclude these tests from gradle build:
junitPlatform {
filters {
tags {
exclude 'integration-test'
}
}
}
So far, so good.
Now I would like to offer a Gradle task which specifically runs my integration tests – what's the recommended approach?
Based on https://github.com/gradle/gradle/issues/6172#issuecomment-409883128
Amended in 2020 to take lazy task configuration and Gradle 5 into account. See answer's history for older versions.
plugins {
id "java"
}
def test = tasks.named("test") {
useJUnitPlatform {
excludeTags "integration"
}
}
def integrationTest = tasks.register("integrationTest2", Test) {
useJUnitPlatform {
includeTags "integration"
}
shouldRunAfter test
}
tasks.named("check") {
dependsOn integrationTest
}
Running
gradlew test will run tests without integration
gradlew integrationTest will run only integration test
gradlew check will run test followed by integrationTest
gradlew integrationTest test will run test followed by integrationTest
note: order is swapped because of shouldRunAfter
History
Gradle 4.6+ supports JUnit 5 natively
JUnit 5 deprecated their plugin: https://github.com/junit-team/junit5/issues/1317
JUnit 5 deleted plugin: 'org.junit.platform.gradle.plugin'
JUnit 5 closed junit5#579 (same as OP's question) as won't-fix (due to decommissioning their plugin)
Gradle supports the above feature: https://github.com/gradle/gradle/issues/6172
Tip
Note: while the above works, IntelliJ IDEA has a hard time inferring stuff, so I suggest to use this more explicit version where everything is typed and code completion is fully supported:
... { Test task ->
task.useJUnitPlatform { org.gradle.api.tasks.testing.junitplatform.JUnitPlatformOptions options ->
options.includeTags 'integration'
}
}
build.gradle.kts
Root project Kotlin DSL drop-in for configuring integration tests in all modules in Gradle 5.6.4
allprojects {
plugins.withId("java") {
#Suppress("UnstableApiUsage")
this#allprojects.tasks {
val test = "test"(Test::class) {
useJUnitPlatform {
excludeTags("integration")
}
}
val integrationTest = register<Test>("integrationTest") {
useJUnitPlatform {
includeTags("integration")
}
shouldRunAfter(test)
}
"check" {
dependsOn(integrationTest)
}
}
}
}
I filed an issue: https://github.com/junit-team/junit5/issues/579 (as suggested by Sam Brannen).
Meanwhile, I am using a project property as a workaround:
junitPlatform {
filters {
tags {
exclude project.hasProperty('runIntegrationTests') ? '' : 'integration-test'
}
}
}
Consequently, integrations tests will be skipped with:
gradle test
but will be included with:
gradle test -PrunIntegrationTests
Gradle 6
I am not sure if it is because Gradle behavior has changed, but the highest voted answer did not work for me in Gradle. 6.8.3. I was seeing the integrationTests task run along with the main test task. This simplified version worked for me:
test {
useJUnitPlatform {
excludeTags "integration"
}
}
tasks.register("integrationTests", Test) {
useJUnitPlatform {
includeTags "integration"
}
mustRunAfter check
}
Commands:
./gradlew test or ./gradlew clean build - Runs tests without
'integration' tag.
./gradlew integrationTests - Only runs test with
'integration' tag.
According to me, the best, current working code to solve this, is the one presented by: TWiStErRob found here.
Note that tests must be tagged with ui in the example below (Junit5 tagging):
task uiTest(type: Test) {
useJUnitPlatform {
includeTags 'ui'
excludeTags 'integration'
}
}
Howe ever, I did not managed to get the Junit5 test-suit-thing to be run from gradle directly witch I would think would be an even nicer solution. But I think the solution buy TWiStErRob, is good enough. The down side is that the gradle.build file now also will be bloated with test-suit-things.
Please note that it is fine to create multiple test suites in the gradle file like this:
task firstTestSuite(type: Test) {
useJUnitPlatform {
includeTags 'test-for-first-test-suite'
}
}
task secondTestSuite(type: Test) {
useJUnitPlatform {
includeTags 'test-for-second-test-suite'
}
}
Then then all could be run separately like this:
gradlew firstTestSuite
gradlew secondTestSuite
gradlew ui
Solution run with Gradle 6.6.1
A similar approach to Rahel Lüthy avoiding the usage of empty strings, in this case to run all tests or just some tags:
test {
useJUnitPlatform() {
if (project.hasProperty("includes")) {
includeTags(project.property("includes") as String)
}
}
}

Resources