System Properties & Environment

## The problem: two different JVMs When Gradle runs your tests, the `Test` task launches a **separate, forked JVM** to execute them. This is distinct from the Gradle daemon JVM that evaluates your build script. A consequence: a system property set on the build (e.g. via `-Dfoo=bar` on the Gradle command line, or `System.setProperty` in a plugin) does **not** automatically appear in your test code. You must explicitly forward it to the test JVM. ## Setting properties on the Test task The `Test` task (the `test` task created by the `java` plugin is of type `org.gradle.api.tasks.testing.Test`) provides: - `systemProperty(name, value)` — add a single property. - `systemProperties` — a mutable `Map<String, Object>` you can assign or `putAll` into. ```kotlin tasks.test { systemProperty("app.env", "ci") systemProperties["db.timeout"] = "5000" } ``` These become `-Dapp.env=ci -Ddb.timeout=5000` on the forked test JVM's command line. ## Reading in test code Inside a JUnit/TestNG test you read them with standard JDK calls: ```kotlin val env = System.getProperty("app.env") ``` ## Bridging from the command line A common pattern is letting a CI pipeline override a value. Pull it from a Gradle property (passed with `-P`) and forward it: ```kotlin tasks.test { systemProperty("app.env", providers.gradleProperty("appEnv").getOrElse("local")) } ``` Now `./gradlew test -PappEnv=staging` reaches the test as `System.getProperty("app.env") == "staging"`. ## Why not just rely on `-D` to Gradle? Because `-Dfoo=bar` passed to `gradlew` sets the property on the **daemon**, not the test fork. It only reaches tests if you also forward it (e.g. `systemProperty("foo", System.getProperty("foo"))`), and doing that reads daemon state, which is brittle and hurts up-to-date checking. Forwarding through the `Test` task explicitly is the clean approach.