Skip to content

Commit f3e93f6

Browse files
committed
Add README
1 parent b6103da commit f3e93f6

File tree

1 file changed

+94
-0
lines changed

1 file changed

+94
-0
lines changed

README.md

Lines changed: 94 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,94 @@
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

Comments
 (0)