Option for adding and extra TestResultCollector when executing tests
Jiri Vanek
jvanek at redhat.com
Mon Aug 11 11:10:33 UTC 2025
On 8/11/25 12:54, Vladimir Sitnikov wrote:
> >This PR is adding junit compatible results output.
> >Would it not be enough for you?
>
> It won't be enough :-/
But custom collector is not enough to help with this:
> I would like to execute jcstress tests with junit-jupiter engine.
Yup, you already wrote about that. Jcstress now can be already started for one tes only, so I do not miss this feature. To do this properly is a lot of work.
However it should be pretty straightforward to generate a junit testfiles, each for test. And you will be able to run it as you described. But then there is question, if this granularity is enough for you, or if you would like to consider
each test variant as separate test.
When I was writing https://github.com/openjdk/jcstress/pull/158, this difference was crucail for me. End I ended to generate both. Because the test by test is not granualr enoug, and the test variants differs to much between HW and jdks.
In case of generated testwrapper, the https://github.com/openjdk/jcstress/pull/158 would be the only missing part.
Note that I;m not sugesting any process spawning (that do jcstress on its own later), but direct executions of individual classes from generated stubs.
> In other words, I would like to execute jcstress-based tests just like I execute JUnit-based tests in my Gradle project:
> ./gradlew test # execute all tests (both JUnit and JCStress)
> ./gradlew test --tests "org.example.concurrency.ConcurrencyTest" # execute a selected test (it could be either JCSTress or JUnit)
Jcstress can be wrapped like this. And it may be much more secure then repalcing the internal runner, which is doing its job pretty well. Especially if you do not care about the dynamic nature of test variants. Such test files can be
easily provided artifact.
>
> At the same time, I want jcstress to report test execution status to Gradle as it executes tests, so a mere xml does not help much.
>
> Vladimir
>
--
Jiri Vanek <j.vanek at ibm.com>
Principal JDK QA engineer
IBM Middleware Czechia s.r.o.
+420 775 39 01 09
More information about the jcstress-dev
mailing list