Is Engine -> Container -> Test structure mandatory? Can it work with just Engine -> Test?

[vlsi]

I'm building a test engine for jcstress, and it looks like Engine -> Test structure does not work, and it looks like JUnit requires to have a container.

For reference, JCStress does not have method-level tests, and it mainly uses @JCStressTest class-level annotation.

I tried the following:

ClassDescriptor.type = Type.TEST and ClassDescriptor.type = Type.CONTAINER_AND_TEST: discovery works, a proper execution request arrives to execute, however, after execution Gradle fails with "No matching tests found in any candidate test task"

ClassDescriptor.type = Type.CONTAINER: discovery does not work (JUnit trims empty containers)

---

If I go with Type.CONTAINER for the class and add a dummy TEST under the container, then everything starts working: Gradle prints the proper test execution status and No matching tests found in any candidate test error goes away.

Could you please clarify if Engine -> Container is vital? I wasn't able to infer it in the documentation

---

It looks like getTestClassNames does not support test is a leaf scenarios due to getAncestors() call at

junit-framework/junit-platform-launcher/src/main/java/org/junit/platform/launcher/core/StackTracePruningEngineExecutionListener.java

Line 49 in 7ebd0a7

return testDescriptor.getAncestors() //

However, it does not seem to be related to Gradle's "no matching tests found"

[sormuras]

An interesting idea! https://github.com/openjdk/jcstress

Marc should be able to answer your questions - otherwise I'll take a deeper look later.

[vlsi]

The idea itself is at #4763.
There's no response from Alexey yet: https://mail.openjdk.org/pipermail/jcstress-dev/2025-July/001385.html.
I'm playing with the jcstress-jupiter-engine in my repository for now: Netcracker/qubership-profiler-agent#240. I wasn't able to work with Engine -> Test mode with Gradle runner which is the current discussion.

---

ChatGPT and Claude did not help me much except Claude (Sonnet) suggested using Engine -> Container -> Test descriptors which happen to work.

[mpkorstanje]

If I go with Type.CONTAINER for the class and add a dummy TEST under the container, then everything starts working: Gradle prints the proper test execution status and No matching tests found in any candidate test error goes away.

Oh! My favorite topic! 😀

Most build tools don't actually support the JUnit Platform. Rather they support JUnit 4. Support for the Jupiter Engine consists of an adapter to the JUnit 4 model of class+method. The JUnit Platform is only supported to the extent that an engine behaves like the JUpiter engine (overly simplified for brevity).

I already complained about this before in #2849 (and more recently cucumber/cucumber-jvm-scala#403).

Could you please clarify if Engine -> Container is vital? I wasn't able to infer it in the documentation

No. That is not vital. But I had a quick look at JCStressTestEngine.execute and see that you're not invoking the EngineExecutionListener for each child of the engine descriptor. That's probably tripping Gradle up because it doesn't see your tests start and stop.

[vlsi]

Thanks for looking into this. Ah, the PR is stale when it comes to listener calls.

I did try adding the following to .execute and it still does not make Gradle detect the execute successful results.

listener.executionStarted(engineDescriptor);
for (TestDescriptor child : engineDescriptor.getChildren()) {
        listener.executionStarted(child);
        listener.executionFinished(child, TestExecutionResult.successful());
}
listener.executionFinished(engineDescriptor, TestExecutionResult.successful());

`

[mpkorstanje]

Ah. Then yeah, I don't think you're going to get it done without a dummy container somewhere.

[marcphilipp]

Engine -> Test will work when using ConsoleLauncher but IIRC Gradle assumes a test class and method structure so you'll need Engine -> Container -> Test for it to work from Gradle.

[mpkorstanje]

It looks like getTestClassNames does not support test is a leaf scenarios due to getAncestors() call at

It looks like StackTracePruningEngineExecutionListener does have JUnit Jupiter semantics where exceptions (to be pruned) are thrown from a user implemented method. It's probably worth creating an issue for that.

[marcphilipp]

Please raise an issue for that. It should also take into account the current TestDescriptor, i.e. "self and ancestors".

[mpkorstanje]

#4828

[vlsi]

Looks like Engine -> Container -> Test is Gradle's requirement: #4825 (reply in thread)