|
| 1 | +A Gradle 7.4+ plugin to turn a [JVM Test Suite](https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html#sec:jvm_test_suite_configuration) |
| 2 | +into **Blackbox** or **Whitebox** Test Suite for Java Modules. |
| 3 | + |
| 4 | +# How to use? |
| 5 | + |
| 6 | +For a quick start, you can find some samples here: |
| 7 | +* [samples/use-all-java-module-plugins](samples/use-all-java-module-plugins) |
| 8 | +* [samples/use-only-java-module-testing-plugin](samples/use-only-java-module-testing-plugin) |
| 9 | + |
| 10 | +For general information about how to structure Gradle builds and apply community plugins like this one to all subprojects |
| 11 | +you can check out my [Understanding Gradle video series](https://www.youtube.com/playlist?list=PLWQK2ZdV4Yl2k2OmC_gsjDpdIBTN0qqkE). |
| 12 | + |
| 13 | +## Plugin dependency |
| 14 | + |
| 15 | +Add this to the build file of your convention plugin's build |
| 16 | +(e.g. `build-logic/build.gradle(.kts)` or `buildSrc/build.gradle(.kts)`). |
| 17 | + |
| 18 | +``` |
| 19 | +dependencies { |
| 20 | + implementation("de.jjohannes.gradle:java-module-testing:0.1") |
| 21 | +} |
| 22 | +``` |
| 23 | + |
| 24 | +## Apply the plugin |
| 25 | + |
| 26 | +In your convention plugin, apply the plugin. |
| 27 | + |
| 28 | +``` |
| 29 | +plugins { |
| 30 | + id("de.jjohannes.java-module-testing") |
| 31 | +} |
| 32 | +``` |
| 33 | + |
| 34 | +## Configure a Blackbox Test Suite |
| 35 | + |
| 36 | +To turn the existing JVM Test Suite _integtest_ ito a Blackbox Test Suite: |
| 37 | + |
| 38 | +``` |
| 39 | +javaModuleTesting.blackbox(testing.suites["integtest"]) |
| 40 | +``` |
| 41 | + |
| 42 | +You can create and/or configure a different test suite as long as you wrap it in `javaModuleTesting.blackbox(...)`. |
| 43 | +See documentation on [JVM Test Suites](https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html#sec:jvm_test_suite_configuration) |
| 44 | +for more details. |
| 45 | + |
| 46 | +It is expected that a blackbox _test source set_ has its own `module-info.java`. |
| 47 | +A blackbox test suite is a separate module itself. |
| 48 | + |
| 49 | +## Configure a Whitebox Test Suite |
| 50 | + |
| 51 | +To turn the existing JVM Test Suite _test_ ito a Whitebox Test Suite: |
| 52 | + |
| 53 | +``` |
| 54 | +javaModuleTesting.whitebox(testing.suites["test"]) { |
| 55 | + requires.add("org.junit.jupiter.api") |
| 56 | + opensTo.add("org.junit.platform.commons") |
| 57 | +} |
| 58 | +``` |
| 59 | + |
| 60 | +You can create and/or configure a different test suite as long as you wrap it in `javaModuleTesting.whitebox(...)`. |
| 61 | +See documentation on [JVM Test Suites](https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html#sec:jvm_test_suite_configuration) |
| 62 | +for more details. |
| 63 | + |
| 64 | +It is expected that a whitebox _test source set_ does **not** have a `module-info.java`. |
| 65 | +Instead, the _main_ and _test_ classes will be patched together and the test will run in the _main_ module which now includes the test classes as well. |
| 66 | +Additional `requires` for the test are defined as shown above. |
| 67 | +If the _sources under test_ are located in a different source set (not `main`), this can be configured via `sourcesUnderTest.set("source-set-name")`. |
| 68 | + |
| 69 | +# What does the plugin do? |
| 70 | + |
| 71 | +The plugin rewires the inputs of test compilation (`:compileTestJava`) and test runtime (`:test`). |
| 72 | +This includes configuring the Module Path and adding patch parameters in the case of whitebox testing. |
| 73 | + |
| 74 | +## Blackbox Test |
| 75 | + |
| 76 | +Changes for test runtime (`:test`): |
| 77 | +- Normally, the test classes are loaded from a `classes` folder |
| 78 | +- Now, the test classes are packaged into a module `jar` together with the test resources. Otherwise, test resources would not be visible to the test module at runtime. |
| 79 | + |
| 80 | +## Whitebox Test |
| 81 | + |
| 82 | +Changes for test compilation (`:compileTestJava`): |
| 83 | +- Normally, Gradle would not use the Module Path, as there is no `moudle-info.java` in the source set |
| 84 | +- Now, a Module Path is computed for the compilation. |
| 85 | + Using `--patch-module`, the test classes are compiled as an addition to the main module. |
| 86 | + |
| 87 | +Changes for test runtime (`:test`): |
| 88 | +- Normally, Gradle would not run its test runner as Module, as there is no `moudle-info.class` as part of the compiled tests. |
| 89 | +- Now, the main and test classes are both used as locations for test discovery. |
| 90 | + By this, Gradle will find the `moudle-info.class` of the main module for the tests. |
| 91 | + Using `--patch-module`, _main classes_, _main resources_, _test classes_, and _test resources_ folders are all merged to be treated as one module during test runtime. |
| 92 | + |
| 93 | + |
| 94 | + |
0 commit comments