Allow use of module-info.java files in unit (whitebox) tests

[brianoliver]

Perhaps I'm missing something here, but it would be nice to allow dependencies to be specified for white box (unit) tests using a module-info.java file instead of having to customize the gradle.build files with kotlin (etc) code.

eg: instead of writing the following:

javaModuleTesting.whitebox(
	testing.suites.getByName<JvmTestSuite>("test") {
		useJUnitJupiter()
		targets.all { testTask { testLogging.showStandardStreams = true } }
	}
) {
	// Modular Dependencies for White Box (unit testing)
	requires.add("org.junit.jupiter.api")
	requires.add("org.junit.jupiter.engine")

	requires.add("org.hamcrest")
        ...
}

It would be nice to be able to write the following module-info.java in the unit test folder, but importantly only when the module name for the unit test exactly matches the name of the main module-info.java file.

// module-info.java in the test/ folder for the module my.app
module my.app {
    requires org.junit.jupiter.api;
    requires org.junit.juptier.engine;
    requires org.hamcrest;
    ...
}

More precisely, we could use the fact that when the module-info.java module name for the white box test exactly matches the module name for the (main) module, we know we have to patch the modules together?

This would even further allow avoiding Gradle dependency hell.

[jjohannes]

Thanks for sharing this idea @brianoliver. This might not be a good fit for every project, but I see how it can be one option this plugin supports.

• If you already use the build.gradle for certain additional dependencies (e.g. runitmeOnly or annotationProcessor) it might be fine to use the build file (in particular in combination with java-module-dependencies). And you might find it confusing to have a test/module-info.java that is not used as such by Java.
• But if you do not use the build.gradle file at all, having the feature proposed here would be great I think.

I might give implementing this a try for the next release. A few thoughts on the feature and its implementation:

• Using the same Module Name as in main/module-infor.java, as you propose, would be a good way to "opt-into" this feature. I like that.
• For the feature, we would need to parse the requires from the module-info.java. Code here can be reused.
• To not have Gradle/Java compile the module-info.java, we would need to add something like the following:

testTask.modularity.inferModulePath.set(false) // maybe (?)
testSourceSets.java.exclude("module-info.java")

• Interaction with java-module-dependencies should keep working. It'll probably work out of the box, but we should check.
• IntelliJ (or other IDE) will most likely complain about the duplicated module, but doing something about that is out of scope for this plugin (maybe adding the testSourceSets.java.exclude("module-info.java") helps here though).

[jjohannes]

I am looking into this. I got something working, but I am not happy yet and I am not sure if there is a good solution:

1. Problem with compilation: The test sources are passed to the compiler via --patch-module. This gives the compiler the whole sources directory. As far as I understand, there is no way to only pass a selection of source files. I can give it a list of .java files, but it still seems to find the root and consider all files in the src/test/java directory. Because of this, it also finds our "fake" module-info.java - which should not be used. The best solution I found so far is to rename the file before calling the compiler and rename it back afterwards. Another option could be to copy and filter the whole folder. But that is changing too much behavior for my taste and compile failures would be reported on the copied files and not the original sources.
2. IDE support (in IDEA): However you turn it, the IDE support is bad. It will show errors in the test code, that classes from the main code are not visible. The only way I have found to solve this is to not have a normal module-info.java file but name it differently or put it somewhere else. This would also solve problem (1). But then there is no IDE support for that file anymore. And naming it differently somehow defeats the original idea. However, having errors shown in the IDE is kind of a no-go for a wider acceptance of such a feature.

[brianoliver]

As an idea, one way to make/trick the IDEs (which I totally agree are pretty shocking) would be to put the module-info.java file in the test/resources folder?

To align ourselves with Java mrjar standards, we could even put them in here?

test/resources/META-INF/versions/9/module-info.java

The IDE is then guaranteed not to touch them (one would hope). I've tested this and it seems to be ok. No need to rename and the grade tool would just work?

It's yuck... but the IDE shouldn't barf, should provide syntax highlighting, there'd be no need to rename and it's in a standard place... Thoughts?

[jjohannes]

Putting it in a different folder is a good idea (if we think it does not defeat the original idea too much). I think putting it into resources is not completely right, because then the uncompiled .java file will be treated as a test resource that's accessible on the test runtime classpath. Also, if I put it there, IntelliJ does not give me any editor support. Probably because it thinks it is just a text file in this case.

What I am thinking is that we could put the file in a separate folder next to test/java. And this folder is not registered as anything containing code or resources in Gradle/IDEA. Then it automatically won't be compiled. Still, IDEA gives a certain tool support for the "stand alone" file.

Maybe using test/java9 as the location is not so bad. You can understand it like: "The test code sill uses old Java modularization (classpath) concepts, but starting with Java 9, we add the module description".

If I would actually write a library where I need to distinguish between code for different Java versions, I would also choose such a layout (see https://github.com/jjohannes/understanding-gradle/tree/main/16_Source_Sets/my-project/app/src/main).

[jjohannes]

When the module info is in a separate folder we also do not necessarily need the naming convention (naming it same as "main" module). No other tooling except this plugin will look at the file. I was thinking if it would be good to have the file written "as if" it was a "blackbox" test. Which means it has a separate name and would need a "requires" on the main module to work.

Like this:

module org.example.app.test {
    requires org.example.app; // the "main" module the test "requires" (into which the test will be patched)

    requires org.junit.jupiter.api;
}

[brianoliver]

Sounds like an awesome plan. I like the idea of developers having to explicitly declare a dependency on the "main" module, mostly because that's what it is and because if one refactored the tests into it's own "real" module, the module-info.java is already done!

Brilliant idea... now does it work?

PS: Having IntelliJ provide some minimal support is pretty cool. Perhaps after seeing this they'll adopt some level of support for it?

[brianoliver]

ASIDE: I'm not too worried about there being an uncompiled module-info.java file in the resources folder.

1. It's just a test resource.
2. Unless someone is compiling and shipping the unit test "module" as a jar, the module-info.java won't be compiled.
3. Even if it is compiled in that location (so there's both a .java and .class version), they are semantically the same. The JVM itself won't care. It would look weird in a compile unit test jar file, but that in itself is weird. I would expect in such a situation that people should be using a "real" module for the test folder, in which case they'd have to have the module-info.java in the correct location.

[jjohannes]

Yes it is working and the change like this is not invasive, as the additional file is only seen and used by this plugin.

This makes it a pure addition to the existing functionality. If you have no other suggestions, I'll release this as 1.3 (see #31). If you use it then and get further/better ideas, we can still improve/change something.

[jjohannes]

Released this as 1.3 – let me know if you run into any issue @brianoliver and/or if you have additional ideas.