This message was deleted.

Can't remember where I found this but I have this in my setup:

test.maxParallelForks = System.getProperty("maxTestParallelForks")?.toInt() ?: ((Runtime.getRuntime().availableProcessors() / 2).takeIf { it > 0 } ?: 1)

That only works in single project build though, not in multi-project. It heavily depends on which parallelism we talk about. There is at least • parallel execution built into JUnit that can even run test methods in parallel • parallel execution using multiple test workers for one test task • parallel execution of test tasks in different projects of a multi-project build • parallel execution of test tasks within the same project

(gradle worker parallelism in a multi-project + junit test class parallelism) coordination is what I refer to above.

What do you mean exactly when you say "JUnit test class parallelism", because all mentioned points run test classes in parallel

systemProperty("junit.jupiter.execution.parallel.enabled", "true")
		systemProperty("junit.jupiter.execution.parallel.mode.default", "same_thread")
		systemProperty("junit.jupiter.execution.parallel.mode.classes.default", "concurrent")

for all tests, and

org.gradle.parallel=true

Unfortunately I don't think there is some easy way to do that, if any way at all.

Sounds lilke a very useful usecase with forever growing number of cores. Is it planned? Haven't found any issue for it.

I heavily doubt it, but I have no idea. It would need a coordination between multiple different VMs.

Yep it would.

I guess if something like that will be supported maybe it has to be on JUnit side, not Gradle side, so that multiple JUnit instances running in different VMs can coordinate the thread count among them.

Thanks, checking with the junit ppl.

It seems a very interesting issue, keep us posted please

One option would be to define an "aggregator" Gradle subproject that defines a Gradle

Test

task and contains a

@Suite

class that runs all tests. That subproject would then have dependencies on the test source sets of all other subprojects.

Sounds like something that could work even if it's not entirely clear how I would do that. So I guess instead of just running

./gradlew test

in CI, you would then run

./gradlew :ci:test

for example which would fork once and let junit engine schedule the tests across the number of cores available. The

@Suite

part looks trivial, but it would be cool if it was possible to automatically add all test source sets (with their corresponding

testImplementation

-deps) dependencies to the hypothetical

:ci:test

task. Sounds doable, but my gradle-fu is too weak to simply envision it. Any suggestions? Otherwise a hardcoded list of dependencies would be fairly low maintenance in my use case.

You should probably define a feature variant for the test source sets and then you can just depend on those feature variants. Much like the

java-test-fixtures

plugin does it, just not with an extra source set. Or you actually use the

java-test-fixtures

plugin and move all your tests into that source set, but I think that is the less clean solution.

I am using java-test-fixtures for test fixtures shared among tests. Don't want to pollute the testfixtures with tests as that would increase compile time as I have a lot of dependencies between test projects and other projects testfixtures. It sounds like the solution suggested by junit would require me to refer to other projects test configurations as implementation dependencies, and possibly also add the superset of all subprojects

test*

-dependencies in the whole project to that

:ci:test

project?

I just told you how to do it. The test fixtures plugin was just an alternative.

Hehe, trying to decipher this archwizard tongue you speak in 🙂 Now that I think of it, it's how this jacoco convention collects its inputs, https://github.com/triplem/gradle-by-example/tree/58c6d92a824e3d0eb52248e2f1e47dfa2cbe371b/buildSrc/src/main/kotlin .. and I happen to have my build convention already imported in all bazillion subprojects already so just need to read and understand how that stuff works. I adapted the jacoco-stuff linked to my build without taking the time to get a deeper understanding of it a couple of months back, should have taken the time, but now is also a great time 🙂

Did you read the documentation about feature variants? https://docs.gradle.org/current/userguide/feature_variants.html As I said, I think the easiest would be if you just define a feature variant for the test source set and then depend on that feature variant. If you want to go the custom consumable configuration route and use it with project accessors, you probably need something like

testImplementation(projects.some.subprojectFoo) { targetConfiguration = "exportedTests" }

No I checked the "Sharing outputs between projects" link you posted. So src/test/kotlin/* can be part of two feature variants and still only be compiled once? Thinking that when running under IDEA the use case would be plain old simple run tests for a subproject, then perhaps run allthe:tests before push which would use whatever solution to get the junit suit to reference all tests in all subprojects and run within the same fork.

So src/test/kotlin/* can be part of two feature variants and still only be compiled once?

By default it is not part of a feature variant, otherwise you could simply use that one. But yes, you can have multiple feature variants for the same code and for example just have different dependencies, or you can have different feature variants that provide different code, many possibilities.

Using the

testRuntimeOnly(projects.foo.somesubproject) { targetConfiguration = "exportedTests" }

strategy for referencing the other artifacts had the same result as

project("...", configuration = "...")

Of course, it is just the project accessors syntax, but effectively the same. Didn't realize there was a problem with the latter.

is that because they are sibling directories or that doesn't matter?

That shouldn't matter, the other project should be found. Hard to say what is wrong there without an MCVE.

Is there any issue with how I register the exportedTests?

Seems fine from a first look. MCVE might help.

Does the names have any significance here?

No, they are freely choosable

Are those two magically related?

No, just what is configured.

It's first after the use of instrumentedClasspath that there comes a declaration in the documentation, is that wrong, or is instrumentedClasspath actually automatically declared by the former steps?

No, no automatism there. It just first shows how to declare the dpendency, but in the build script you actually should have the configuration created first.

without any need of creating jars or whatnot.

That's why I said you should use a feature variant. That makes the jar task declaring and so on for you implicitly.

Ok, thanks for your immense patience. Next attempt will be with feature variant.

Feel free to open a feature request ticket that suggests it, there were no Gradle guys in this discussion and even if, it would probably need a feature request or PR. :-)