Failed and skipped methods leave thread in interrupted state

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Failed and skipped methods leave thread in interrupted state


I believe this is a TestNG bug, but first I'm asking if this makes sense the the group.

On 6.14.3 and 6.14.2, if I run tests with class parallelization and a timeout, then the thread on which tests run is in an interrupted state after a failed or skipped test and when the next test or configuration method begins.

I've attached a little project to demonstrate. You can unzip it and run 'mvn clean install' to see the failures.

I've seen this happen after configuration methods have failed with exceptions as well, not just tests.

This breaks our config and test methods because they'll attempt to wait for some reason and immediately die with an InterruptedException since the thread was in the interrupted state from the beginning.

I have a workaround that's a little clunky: I create a listener that checks if the thread is interrupted after each test and configuration method, and clears the state if so. This prevents the problem, but is not ideal; I haven't yet looked into order of listener execution to know if other listeners might still run into trouble if they run first. This does show that the thread is in the interrupted state when the listener runs on all after events for tests and configuration methods for every test skip and failure.

Note that if you run tests without a timeout, you don't see the problem.

In the attachment, there are 6 tests that run in order. 
  1. testThatSkips: Explicitly throws SkipException
  2. testThatIsNotOnInterruptedThread: This asserts the thread is not interrupted. It fails.
  3. testThatFails: throws a runtime exception after clearing the interrupted state
  4. testThatIsNotOnInterruptedThread2: This asserts the thread is not interrupted. It fails.
  5. testThatFailsWithoutTimeout: Throws a runtime exception after clearing the interrupted state
  6. testThatIsNotOnInterruptedThread3: This asserts the thread is not interrupted. If works.
I'd expect tests 2 and 4 above to succeed.

I believe that the issues persists if the thread is re-used for another test class. I didn't write tests for this in the attached example, but I've seen where if one tests fails, the next test to run on the same thread fails with InterruptedException even when the test is from a different class. My listener workaround prevents these also, at least so far.

I believe TestNG is not clearing the state properly after a skip or fail when using a timeout, and I think it doesn't do it if a configuration method fails or skips either -- they looked to be treated in the same way in the code, and I have seen it happen on configuration methods.

I don't know if it happens if you don't use class parallelization.

I think a related problem was mentioned in, but it seems a separate issue. Any assistance appreciated. Thanks,


You received this message because you are subscribed to the Google Groups "testng-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at
For more options, visit (4K) Download Attachment