RFR: 8301767: Convert virtual thread tests to JUnit [v2]

Alan Bateman alanb at openjdk.org
Wed Feb 8 09:51:46 UTC 2023


On Wed, 8 Feb 2023 09:39:37 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> test/jdk/java/lang/Thread/virtual/GetStackTrace.java line 31:
>> 
>>> 29:  * @enablePreview
>>> 30:  * @modules java.base/java.lang:+open
>>> 31:  * @run main GetStackTrace
>> 
>> That's interesting - so this test was marked as a testng test previously, but had not test methods in it. I had a look at the test run history of this one and I see that the test execution results in:
>> 
>>> java/lang/Thread/virtual/GetStackTrace.java
>>> Total tests run: 0, Passes: 0, Failures: 0, Skips: 0
>> 
>> I wonder if testng (and junit) can be configured to fail the test if no test methods were present, to flag such mistakes.
>> 
>> Keeping that aside, the change to make this `@run main` looks fine.
>> 
>> As for adding the `@requires vm.continuations`, I'm not familiar with its expectations. Looking at the test case, it just captures stacktraces using `Thread.getStackTrace()` and then just does some basic validation of those stacktrace elements. Do we use this `@requires vm.continuations` even in such tests?
>
>> I wonder if testng (and junit) can be configured to fail the test if no test methods were present, to flag such mistakes.
> 
> JUnit's CLI tool has:
> 
> `--fail-if-no-tests     Fail and return exit status code 2 if no tests are found.`
> 
> We can add such a check into `jtreg`'s JUnit runner at
> https://github.com/openjdk/jtreg/blob/524161b73dca250639ad3f00a42518e384276906/src/share/classes/com/sun/javatest/regtest/agent/JUnitRunner.java#L149-L151

> As for adding the `@requires vm.continuations`, I'm not familiar with its expectations. Looking at the test case, it just captures stacktraces using `Thread.getStackTrace()` and then just does some basic validation of those stacktrace elements. Do we use this `@requires vm.continuations` even in such tests?

Yes, it is needed as the alternative implementation of virtual threads (used on x86_32 and a few other ports) don't allow custom schedulers.

-------------

PR: https://git.openjdk.org/jdk/pull/12426


More information about the serviceability-dev mailing list