I have integration tests named with "IT" at the end and the tests are excluded by default. My build.gradle contains:
test {
if (!project.hasProperty('runITs')) {
exclude '**/**IT.class'
}
}
The check task, which is part of build, no longer runs integration tests. All tests (unit + integration) are executed with defined runITs (e.g. ./gradlew -PrunITs=1 check) if it is necessary.
It works very well. The only drawback is than I can't run single integration test with --test (used by IDE) without runITs defined. The command fails with message: No tests found for given includes: [**/**IT.class](exclude rules).
Is there any way (e.g. build variable) how to recognize the run of single test with --test and skip the exclusion?
I have found a solution. My build.gradle now contains:
test {
if (!project.hasProperty('runITs') && filter.commandLineIncludePatterns.empty) {
exclude '**/**IT.class'
}
}
When tests are run with --tests then the list commandLineIncludePatterns in filter is not empty and exclude is not applied.
Details are obvious in test task source: https://github.com/gradle/gradle/blob/dc8545eb1caf7ea99b48604dcd7b4693e79b6254/subprojects/testing-base/src/main/java/org/gradle/api/tasks/testing/AbstractTestTask.java
try invoking the test task to the specific sub-project. if the test is root try
gradle -PrunITs=1 :test --tests 'MServiceTest'
else
gradle -PrunITs=1 :sub-prj:test --tests 'MServiceTest'
I'm working on a Java project that uses Gradle as its build system.
I want to add some bdd tests using Cucumber-JVM. Following this example I was able to configure Gradle's build.gradle to have a task called cucumber, and I was able to execute that task using "gradle cucumber".
But what I am looking for is a way to have Gradle run that task automatically during its test phase (where it runs all the other regular unit tests). I also want the build to be flagged as failed if any of the cucumber tests fail (strict=true).
Is this possible? I don't know a lot about Gradle and Google so far has produced nothing really useful.
Okay so I figured out how to achieve this. Simply add this to build.gradle:
test << {
javaexec {
main = "cucumber.api.cli.Main"
classpath = configurations.cucumberRuntime + sourceSets.main.output + sourceSets.test.output
args = ['--strict', '--monochrome', '--plugin', 'pretty', '--glue', 'com.mypackage', 'src/test/resources']
}
}
All you really need are the feature file and the steps java files that implement the glue code. You do not need the xxxCukesTest.java file with a #RunWith annotation since Gradle ignores it. You may want to keep it anyway because it enables you to run tests from your IDE.
Works really neat!
As the title says, how can I make gradle not to fail a test task if no tests are found? I ran into this problem when I was using the --tests command line option with a multi-subproject project. For instance, this command below will run all tests in class FooTest from subproject A:
gradle test --tests com.foo.bar.FooTest
However, this command fails because of something like this:
Execution failed for task ':B:test'.
> No tests found for given includes: [com.foo.bar.FooTest]
BTW, I know something like below will succeed. But is it possible to make it succeed even with the test task? It's kind of annoying to type a test task name longer than test.
gradle :A:test --tests com.foo.bar.FooTest
The behavior you described is the current Gradle behavior, there is already a ticket on Gradle forum, see https://discuss.gradle.org/t/multi-module-build-fails-with-tests-filter/25835
Based on the solution described in this ticket, you can do something like that to disable the 'failIfNoTest' default behavior:
In your root project build (or better: in an InitScript in your Gradle USER_HOME dir, to make this behavior available for all your local projects)
gradle.projectsEvaluated {
subprojects {
// TODO: filter projects that does not have test task...
test {
filter {
setFailOnNoMatchingTests(false)
}
}
}
}
Then you can execute the following command without having errors if the given test doesn't exist in all sub-projects:
gradle test --tests com.foo.bar.FooTest
it seems that currently only a workaround like this is possible:
test {
afterSuite { desc, result ->
if (!desc.parent) {
if (result.testCount == 0) {
throw new IllegalStateException("No tests were found. Failing the build")
}
}
}
}
I have filed an issue with Gradle to introduce this as a simple config option: https://github.com/gradle/gradle/issues/7452
You can also run the tests only for the current project with
gradle :test --tests com.foo.bar.FooTest
Note the colon before the test task.
I'm using Gradle spring-boot plugin and I need to select a spring active profile for the test run.
How do I pass spring.profiles.active system property to the bootRun plugin's task?
What has already failed:
task bootRunLocal {
systemProperty "spring.profiles.active", "local"
System.setProperty("spring.profiles.active", "local")
tasks.bootRun.execute() // I suspect that this task is executed in a separate JVM
}
and some command line magic also fails:
./gradle -Dspring.profiles.active=local bootRun
Could someone kindly help me solve my troubles?
Update from the answers and comments:
I'm able to set the systemProperty and pass it to the spring container by doing :
run {
systemProperty "spring.profiles.active", "local"
}
However, when I do this, the local profile is being set for both bootRun task and bootRunLocal task. I need a way to set this property for bootRunLocal task and call booRun task from bootRunLocal.
That might sound very simple, but I come with peace from the structured world of Maven.
I know I'm late here... but I recently faced this exact issue. I was trying to launch bootRun with spring.profiles.active and spring.config.location set as system properties on the command line.
So, to get your command line "magic" to work, simply add this to your build.gradle
bootRun {
systemProperties System.properties
}
Then running from the command line...
gradle -Dspring.profiles.active=local bootRun
Will set local as the active profile, without needing to define a separate task simply to add the env variable.
task local {
run { systemProperty "spring.profiles.active", "local" }
}
bootRun.mustRunAfter local
Then run gradle command as:
gradle bootRun local
There is no generic way to pass system properties to a task. In a nutshell, it's only supported for tasks that fork a separate JVM.
The bootRunLocal task (as defined above) will not execute in a separate JVM, and calling execute() on a task isn't supported (and would have to happen in the execution phase in any case). Tests, on the other hand, are always executed in a separate JVM (if executed by a Test task). To set system properties for test execution, you need to configure the corresponding Test task(s). For example:
test {
systemProperty "spring.profiles.active", "local"
}
For more information, see Test in the Gradle Build Language Reference.
SPRING_PROFILES_ACTIVE=local gradle clean bootRun
This is according to this and this and it works.
According to the spring-boot-gradle-plugin documentation you should be able to pass arguments like this
./gradlew bootRun --args='--spring.profiles.active=dev'
Seems like this is a new gradle feature since 4.9. I used it in my project and it worked out of the box.
For gradle 2.14 below example works.
I have added as below.
When System.properties['spring.profiles.active'] is null then default profile is set.
bootRun {
systemProperty 'spring.profiles.active', System.properties['spring.profiles.active']
}
command line example
gradle bootRun -Dspring.profiles.active=dev
Just for reference if anyone will have this issue:
Vlad answer didn't quite worked for me but this one works great with 2.4,
task local <<{
bootRun { systemProperty "spring.profiles.active", "local" }
}
local.finalizedBy bootRun
then gradle local
Responding to OP's exact request here ...
How do I pass spring.profiles.active system property to the bootRun plugin's task?
And assuming by "pass" the OP meant "pass from commandline" or "pass from IDE invocation" ... This is how I like to do it.
Add this to build.gradle:
/**
* Task from spring-boot-gradle-plugin, configured for easier development
*/
bootRun {
/* Lets you pick Spring Boot profile by system properties, e.g. gradle bootRun -Dspring.profiles.active=dev */
systemProperties = System.properties
}
Then when you invoke it, use the familiar Java flag for setting a system property
gradle bootRun -Dspring.profiles.active=local
There is one main advantage of sticking to system properties, over the environment variables option (SPRING_PROFILES_ACTIVE=local gradle bootRun) ... and that's easy portability between Linux/OS X (bash, etc.) and Windows (cmd.exe anyway).
I learned this way from this blog post.
(UPDATE: Ah somehow I had missed #Erich's response with same recommendation. Oops! I'm leaving my answer, because of the additional details about portability, etc.)
You can create a new task (in discussed case with name bootRunLocal), that would extend org.springframework.boot.gradle.run.BootRunTask and setup properties before task execution. You can create such a task with following code:
task bootRunLocal(type: org.springframework.boot.gradle.run.BootRunTask) {
doFirst() {
main = project.mainClassName
classpath = sourceSets.main.runtimeClasspath
systemProperty "spring.profiles.active", "local"
}
}
More details can be found here:
https://karolkalinski.github.io/gradle-task-that-runs-spring-boot-aplication-with-profile-activated/
Starting from SpringBoot 2.0.0-M5 setSystemProperties() is no longer a method of the task bootRun.
The build.gradle needs to be updated to
bootRun {
execSpec {
// System.properties["spring.profiles.active"]
systemProperties System.properties
}
}
This is as springBoot's run task uses org.gradle.process.JavaExecSpec
This works for me using Gradle 4.2
This works:
SPRING_PROFILES_ACTIVE=production ./gradlew app-service:bootRun
with run command you can add to build file run { systemProperties = System.properties } and start with gradle run -Dspring.profiles.active=local
Another way which doesn't require any support from the gradle task: Set the JAVA_TOOL_OPTIONS environment variable:
JAVA_TOOL_OPTIONS='-Dfoo=bar' gradle ...
Or if the variable might already contain anything useful:
JAVA_TOOL_OPTIONS="$JAVA_TOOL_OPTIONS -Dfoo=bar" gradle ...
// defualt value
def profiles = 'dev'
bootRun {
args = ["--spring.profiles.active=" + profiles]
}
Then you can simply pick a specific version when starting a gradle task, like
./gradlew bootRun -P dev
"dev" is gonna to take place "prod"
I'm new with Gradle.
My problem:
Is it possible to switch between test suites in "Gradle test" depending on parameter?
Something like:
test {
useTestNG()
{
suites 'src/test/resources/testng-'+input_parameter_as_string+'-Test.xml'
useDefaultListeners = true
}
My goal is to call: gradle test "input_parameter_as_string".
Hope you guys can help me out.
Gradle documentation lists some ways to run specific test using system property: http://www.gradle.org/docs/current/userguide/userguide_single.html#sec:java_test . To run multiple correlated tests, you can try test group (both TestNG and Gradle supports): http://testng.org/doc/documentation-main.html#test-groups .
If you insist to use your custom closure, you can always use project property. In build.gradle:
test {
useTestNG()
{
suites 'src/test/resources/testng-' + project.ext.input_parameter_as_string +'-Test.xml'
useDefaultListeners = true
}
and in command line:
gradle test -Pinput_parameter_as_string=testFoobar.
Out of the box, Gradle supports running a single test:
./gradlew test -Dtest.single=MyTestClassName