How to give System property to my test via Gradle and -D

Question

I have a a Java program which reads a System property

System.getProperty("cassandra.ip");

and I have a Gradle build file that I start with

gradle test -Pcassandra.ip=192.168.33.13

or

gradle test -Dcassandra.ip=192.168.33.13

however System.getProperty will always return null.

The only way I found was to add that in my Gradle build file via

test {
    systemProperty "cassandra.ip", "192.168.33.13"
}

How Do I do it via -D

Solution 1

The -P flag is for gradle properties, and the -D flag is for JVM properties. Because the test may be forked in a new JVM, the -D argument passed to gradle will not be propagated to the test - it sounds like that is the behavior you are seeing.

You can use the systemProperty in your test block as you have done but base it on the incoming gradle property by passing it with it -P:

test {
    systemProperty "cassandra.ip", project.getProperty("cassandra.ip")
}

or alternatively, if you are passing it in via -D

test {
    systemProperty "cassandra.ip", System.getProperty("cassandra.ip")
}

Solution 2

Came across this very much problem, except i don't want to list all properties given on the commandline in the gradle script again. Therefore i send all system properties to my test

task integrationTest(type: Test) {
    useTestNG()
    options {
        systemProperties(System.getProperties())
    }
}

Solution 3

I had a case where I needed to pass multiple system properties into the test JVM but not all (didn't want to pass in irrelevant ones). Based on the above answers, and by using subMap to filter the ones I needed, this worked for me:

task integrationTest(type: Test) {
    // ... Do stuff here ...
    systemProperties System.getProperties().subMap(['PROP1', 'PROP2'])
}

In this example, only PROP1 and PROP2 will be passed in, if they exist in gradle's JVM.

Solution 4

Here's a variant that passes numerous project properties to the test JVM as system properties. I prefer project properties over system properties to increase flexibility.

task intTest(type: Test) {
    systemProperties project.properties.subMap(["foo", "bar"])
}

Which may be passed on the command-line:

 $ gradle intTest -Pfoo=1 -Pbar=2

And retrieved in your test:

String foo = System.getProperty("foo");

Solution 5

So I've stumbled on that issue today as well, and what worked for me was the following:

ext.env='prod'
test {
  systemProperty 'env', System.properties['env'] ?: "${env}"
  println "# test environment: " + systemProperties['env']
  ...
}

I'm calling my test task using -Penv=dev and I get my 'dev' value in my print, or 'prod' if I do not send any value, which is the expected behavior for me.

Value is also accessible on java side, using System.getProperty("env").

My conclusion on the matter is that input value (parameter) is actually stored under System, making it accessible through either System.properties['env'] or System.getProperty("env"), whereas output (system property) is stored in a systemProperties array, making it readable through systemProperties['env'].

View more solutions

Comments

[JB Nizet]

What happens when you use gradle -Dcassandra.ip=192.168.33.13? Anyway, the test task forks one or several new JVMs. So you'll have to pass properties explicitely. Nobody forces you to hardcode their value in the build, though.

[IgalS]

Also take a look in this answer: stackoverflow.com/questions/23689054/…

[CLOVIS]

This doesn't work for me (tested using System.getProperties().stringPropertyNames().forEach(System.‌​out::println); in the Java code, it doesn't appear)

[Yngvar Kristiansen]

Warning: getProperty throws MissingPropertyException if property is not found. Use Eron's answer instead: stackoverflow.com/a/43112126/915441

[Yngvar Kristiansen]

When running System.getProperty("someprop") using that subMap method, I got {someprop=foo} instead of foo. I had to use systemProperty "foo", project.properties.subMap(["foo"]).get("foo") in build.gradle

[Duncan Calvert]

Adding default values to gradle.properties will prevent the MissingPropertyException.

[Hester Lyons]

@YngvarKristiansen where (how) were you using systemProperty "foo"? i.e. I'm asking to see the full line of code where this was used? I'm trying everything suggested in this question and still Gradle is not passing any arguments. Hoping this might resolve!

[Hester Lyons]

I can get neither of these methods to work. Whatever I do myProperty is always null. This includes all of the methods mentioned below, too. I am wondering if this is something to do with a more recent version, as all comments are from 2018? @CLOVIS did you find a solution to this?

[CLOVIS]

@HesterLyons I only wanted to know if the build was testing or normally running, so I used the property gradle itself adds when testing; you can see the code here: github.com/CLOVIS-AI/wildfyre-java/blob/master/src/main/java‌​/…

[Yngvar Kristiansen]

@HesterLyons I'm sorry, I didn't keep my code, so I don't know anymore :\ I agree that it looks out of place.

[Hester Lyons]

Thank you @YngvarKristiansen. I have since worked out that my problem was being caused by the junit gradle plugin which was included in my gradle.build. Very odd.

[thokuest]

Be careful when doing this. It might easily break Gradle's up-to-date checks when system properties change during invocations.

[Dinu Nicolae]

Same for JavaExec tasks. The props were present in the task, but not in the java program, unless the were set again in the task.