Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a watcher (JUnit 3) test rule (JUnit 4) for hanging test logging #774

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

HeikoKlare
Copy link
Contributor

Tests may be (and actually are every now and then) hanging for different reasons, such as livelocks or deadlocks. A hanging test does not log anything on its own anymore, which makes it difficult to identify a hanging test and the reasons for that. To this end, it would be useful to have an additional entity that logs the state of all threads, i.e., a thread dump, when a test takes longer than a defined threshold.

Since several tests need to run in the UI thread, the JUnit Timeout rule cannot be used, as it executes a test in a different thread that can even be terminated preemptively after a timeout. Instead, this change introduces a HangingTestRule that spawns a watcher thread that writes a thread dump whenever a test (that is run in the UI thread) takes more time than a defined timeout.
In total, this change does the following:

  • Makes the thread dump logic currently placed in TestBarrier2 reusable in a central TestUtil
  • Adds a HangingTestWatcher that writes a thread dump if not stopped after a given timeout (compatible with JUnit 3)
  • Adds a HangingTestRule that wraps the HangingTestWatcher into a JUnit 4 rule
  • Adds the HangingTestWatcher to the JUnit 3 CoreTest class to apply the logging to all subclasses of CoreTest

Also see eclipse-platform/eclipse.platform.ui#1229, which discusses some additional logging in Platform UI to help debugging hanging tests. That may be replaced by the proposed watcher/rule.

@github-actions
Copy link
Contributor

github-actions bot commented Oct 26, 2023

Test Results

     534 files  ±0       534 suites  ±0   1h 11m 13s ⏱️ + 8m 5s
  3 793 tests ±0    3 787 ✔️  - 1    5 💤 ±0  1 +1 
12 000 runs  ±0  11 963 ✔️  - 1  36 💤 ±0  1 +1 

For more details on these failures, see this check.

Results for commit 1dd26d0. ± Comparison against base commit d0ec0a8.

♻️ This comment has been updated with latest results.

@HeikoKlare HeikoKlare force-pushed the hanging-test-logging branch 5 times, most recently from 112221b to b92016e Compare October 27, 2023 16:04
Tests may be (and actually are every now and then) hanging for different
reasons, such as livelocks or deadlocks. A hanging test does not log
anything on its own anymore, which makes it difficult to identify a
hanging test and the reasons for that. To this end, it would be useful
to have an additional entity that logs the state of all threads, i.e., a
thread dump, when a test takes longer than a defined threshold.

Since several tests need to run in the UI thread, the JUnit Timeout rule
cannot be used, as it executes a test in a different thread that can
even be terminated preemptively after a timeout. Instead, this change
introduces a HangingTestRule that spawns a watcher thread that writes a
thread dump whenever a test (that is run in the UI thread) takes more
time than a defined timeout.
In total, this change does the following:
- Makes the thread dump logic currently placed in TestBarrier2 reusable
in a central TestUtil
- Adds a HangingTestWatcher that writes a thread dump if not stopped
after a given timeout (compatible with JUnit 3)
- Adds a HangingTestRule that wraps the HangingTestWatcher into a JUnit
4 rule
- Adds the HangingTestRule to the ResourceTest class to apply the
logging to all subclasses that are executed with JUnit 4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant