JDK-8328629 : JUnit test without a timeout value can hang indefinitely
  • Type: Bug
  • Component: javafx
  • Sub-Component: other
  • Affected Version: jfx22
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-03-20
  • Updated: 2024-10-14
  • Resolved: 2024-09-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
jfx24 b11Fixed
Related Reports
Blocks :  
JDK-8339510 - [TestBug] Convert system tests to JUnit 5
Relates :  
JDK-8238505 - [macOS] Intermittent deadlock on exit in MacTimer
Relates :  
JDK-8339170 - ☂ Convert tests to JUnit 5
Relates :  
JDK-8340405 - JavaFX shutdown hook can hang preventing app from exiting
Description
The JUnit `@Test` annotation takes an optional timeout parameter that will abort the test after a certain amount of time.

In the absence of this optional parameter, gradle's test runner, which is used to run our JUnit tests, will run indefinitely. We should explore whether there is a way to set a default timeout when one is not specified.

The lack of such a global timeout is a problem when running automated tests using a Jenkins (or similar) build system.

WORKAROUND: The only feasible workaround is to have a global job timeout on the Jenkins job. That is problematic since the timeout would need to be very long (on the order of 4 hours) to ensure that a build and test run done on a slower system was never killed prematurely.
Comments
Changeset: 29004352 Branch: master Author: Kevin Rushforth <kcr@openjdk.org> Date: 2024-09-24 17:00:31 +0000 URL: https://git.openjdk.org/jfx/commit/29004352006e4d1d01401d658d22a35ae2648de5
24-09-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jfx/pull/1575 Date: 2024-09-19 14:15:23 +0000
19-09-2024
Since we are now in the process of converting our tests to JUnit 5, I'll start working on this next week.
13-09-2024
Glad that this works as expected. I also don't know of any way in JUnit 4 unfortunately (and I also only use JUnit 5 in daily work normally). The lifecycle timeout sounds good as well.
21-03-2024
If we go forward with the JUnit5 system property, we should consider also setting a default timeout (possibly shorter) for lifecycle methods: junit.jupiter.execution.timeout.lifecycle.method.default since the test timeout that prompted me to file this bug could easily impact a Platform.exit call in an `@AfterAll` method (and we've occasionally seen timeouts in other lifecycle methods).
20-03-2024
Thanks for the pointer. From the Timeout annotation docs, I see that you can set the default timeout via a system property: junit.jupiter.execution.timeout.test.method.default I verified that this works as expected, for Junit5 tests, which is great, since it means that we don't have to remember to opt-in to the default on a per-test-class basis. I didn't find any good way to do the same for JUnit4 tests, so maybe this is a good reason to accelerate the conversion of existing tests to JUnit5.
20-03-2024
This may help for JUnit5: https://junit.org/junit5/docs/5.9.1/api/org.junit.jupiter.api/org/junit/jupiter/api/Timeout.html Not sure about JUnit4 though. Maybe it makes sense to start migrate some tests to JUnit5? This is something where I can help as well.
20-03-2024
This is more than a theoretical concern. We have seen an increase of occurrences of JDK-8238505 lately causing our nightly headful test run to occasionally hang on one of our macOS systems until we notice it and kill it manually.
20-03-2024