GRADLE: TestNg - unable to pass -D parameter to java code

Question

I have a Test framework written in Java utilizing TestNg, and built using gradle. I want to pass an 'environment' argument at the command line, which will be used in an Environment class to define domain and server values for specific environments. Using the Gradle documentation and several forum discussions on this issue, I am still unable to get the argument passed as a system property to the framework. I have tried to accomplish this from the 'test' task AND the 'debug' task, to NO avail. A 'println' statement in the task shows that the -Denv parameter is being picked up by gradle, but my attempt to add it to the System properties for the test framework fails.

Execution results in a null reference, with environmentName being set to null.

Can someone identify my error?

command line

.\gradlew debug -Denv=production

build.gradle

test {
    def environment = System.properties["env"]
    println environment
    systemProperties = System.getProperties()
    systemProperties['env'] = environment
    useTestNG()
}

task debug(type: Test) {
//    def environment = System.properties["env"]
//    println environment
//    systemProperties = System.getProperties()
//    systemProperties['env'] = environment
    def groupsToInclude = []
    def groupsToExclude = []

    groupsToInclude.add('under_development')
    useTestNG() {
        groupsToInclude.each { String group -> includeGroups group }
        groupsToExclude.each { String group -> excludeGroups group }
    }
}

java class

import com.sun.javafx.runtime.SystemProperties;

public class Environment {

    private static EnvironmentDefinition environment;

    private Environment() {
    }

    public static EnvironmentDefinition getInstance() {
        if (environment == null) {
            String environmentName = SystemProperties.getProperty("env");
            // environmentName = environmentName == null ? "production" : environmentName;
            switch (environmentName) {
                default:
                    Environment.environment = ProductionEnvironment.getInstance();
            }
        }
        return environment;
    }
}

This might help ... Add this as the line just before the `exec` in gradel shell-script - `echo "$JAVACMD" "${JVM_OPTS[@]}" -classpath "$CLASSPATH" org.gradle.launcher.GradleMain "$@" `. The next line should be exec. Report the output. — Prashant, Sep 28 '15 at 03:18

score 3 · Accepted Answer · edited May 23 '17 at 12:00

3

It all works well, please have a look at the demo I prepared. Mind the fact that you cannot set the system property to null value - it might be a problem as well.

edited May 23 '17 at 12:00

Community

1
1

answered Sep 28 '15 at 07:48

Opal

81,889
28
189
210

Opal, thank you for the sample code. It eventually led to my mistake. – CStockton Sep 28 '15 at 22:58
@Craig, if you found it helpful, please at least upvote it. – Opal Sep 29 '15 at 04:13
Ah..newbie to submitting/responding to questions/answers in stackoverflow. Your answer has been approved. =0) – CStockton Sep 30 '15 at 17:19

score 1 · Answer 2 · answered Sep 28 '15 at 22:57

"It's System, you dummy...not SystemProperties!...

Isn't it always the most simple oversights that cause the most trouble?

After cloning Opal's solution along side mine, and bringing them into alignment one step at a time, I noticed that in the java code my reference was to SystemProperties.getProperty(), rather than System.getProperty().

score 0 · Answer 3 · edited May 23 '17 at 12:24

0

A better solution might be to add the property in your .gradle/gradel.properties file, with the property set to what applies to that machine. See if that works. For example, you might set it to DEV on your machine, but BUILD on another machines. That way you don't have to enter it every time. See this question about customizing build by environment. There are advantages and disadvantages to this approach.

Hope this helps.

edited May 23 '17 at 12:24

Community

1
1

answered Sep 28 '15 at 03:24

Prashant

1,002
13
29

Unless I misunderstand, this approach would work if the tests were being executed on the machine being tested. In this case, the tests are being executed on a separate machine (build slave), with access to multiple environments. Test code being built and executed on the slave needs to know which urls and connection strings to use, based on the environment being validated. – CStockton Sep 28 '15 at 20:10

GRADLE: TestNg - unable to pass -D parameter to java code

3 Answers3