Testing Integration

Configure the Test task with systemProperty("key", "value") (or test { systemProperty ... }). In the test, read it with System.getProperty("key"). It is set on the forked test JVM, not the build JVM.

Setting test.ignoreFailures = true tells Gradle not to fail the build when tests fail. The test task still runs all tests and reports results, but a failing test no longer marks the build as failed.

Tests run in a separate forked JVM. On the test task set minHeapSize and maxHeapSize (e.g. "256m" / "1g"). These map to the forked JVM's -Xms and -Xmx, not the Gradle daemon's heap.

maxParallelForks sets how many test JVM processes Gradle runs at once for a single Test task. Set it in the test task config, e.g. tasks.test { maxParallelForks = 4 }. Default is 1.

Call useJUnitPlatform() on the Test task in build.gradle.kts, e.g. tasks.test { useJUnitPlatform() }. Without it Gradle defaults to the JUnit 4 (Vintage) runner and won't discover Jupiter tests.

Add implementation(project()) inside the suite's dependencies { } block. The bare project() call refers to the current project, so the suite compiles and runs against main classes.

It is a DSL from the built-in jvm-test-suite plugin for declaring test suites (groups of tests). It is applied automatically by the java plugin and exposes a default suite named test.

Inside the testing.suites block, register a suite with val integrationTest by registering(JvmTestSuite::class). Gradle then auto-creates the integrationTest source set, the integrationTest task, and its dependency configurations — no manual source-set wiring needed.

Go through the suite's targets: targets { all { testTask.configure { useJUnitPlatform() } } }. Each target exposes a testTask provider you configure, instead of touching the top-level test task directly.

Custom suites don't inherit testImplementation. The library was declared only for the test suite, so the integration suite never saw it. Fix: declare it in the integrationTest suite's dependencies { }, or make integrationTestImplementation extend testImplementation.

The JUnit BOM is a Bill of Materials that declares one consistent version for all JUnit modules (Jupiter, Platform, Vintage). Importing it with platform(...) lets you list JUnit dependencies without versions, so they all align.

Call useJUnitPlatform() on the test task. By default Gradle uses the JUnit 4 runner, so you must opt into the JUnit Platform for Jupiter tests to be detected and executed.

They added only the API, not the engine. Without junit-jupiter-engine on testRuntimeOnly the Platform has nothing to discover the tests. Add the engine (or the junit-jupiter aggregator) and the tests run.

Add the TestNG dependency to testImplementation, then call useTestNG() inside the test task. Without useTestNG(), Gradle assumes JUnit and won't detect @Test annotations from TestNG.

Vintage is a JUnit Platform TestEngine that runs JUnit 4 tests. Add testRuntimeOnly('org.junit.vintage:junit-vintage-engine') and call useJUnitPlatform() in the test task so Gradle discovers and runs them.

It's a core Gradle plugin that merges the test results of multiple subprojects into a single combined HTML report, so you don't have to open each subproject's report separately.

The filter {} block on a Test task selects which tests run by pattern. includeTestsMatching('*Foo*') keeps only matching tests; excludeTestsMatching drops matching ones. Patterns match fully-qualified class/method names with * wildcards.

Gradle writes an HTML report under build/reports/tests/test/ (open index.html in a browser) and machine-readable JUnit-XML under build/test-results/test/. You open the HTML in a browser.

Use the --tests flag on the test task: ./gradlew test --tests 'com.example.MyTest' runs one class, and ./gradlew test --tests 'com.example.MyTest.myMethod' runs one method.

Apply test-report-aggregation on an aggregating project, add each subproject via the testReportAggregation dependency configuration, then run testAggregateTestReport to get one merged HTML report.

Add jacoco to the plugins {} block. Gradle then adds a jacocoTestReport task and a jacoco {} extension, and instruments your tests so coverage data is collected when you run test.

GradleRunner is the TestKit entry point that runs a real Gradle build against a temporary project directory. You create it, point it at a project dir, pass arguments, and call build() to execute and inspect the result.

It's a JaCoCo plugin task that checks coverage against rules you define in violationRules. If coverage is below the configured minimum, the task fails, which fails the build.

Check that each module applies jacoco/jvm-test-suite (so it exposes coverage variants), that its tests actually ran and produced .exec data, that it's reachable via jacocoAggregation, and that the right testSuiteName is aggregated.

It merges JaCoCo coverage data from several subprojects into one combined HTML/XML report, so you see total coverage across the whole multi-project build instead of per-module reports.