JUnit @Test(timeout) exception timing relative to test method completion

Answer

In both JUnit 4 and JUnit 5 the @Test(timeout) (or JUnit 5 @Timeout) does not wait for the test method to finish normally; it interrupts the thread running the test and reports a TestTimeoutException from the main test‑running thread.

Confirmed facts

• JUnit 4 implements the timeout via org.junit.internal.runners.statements.FailOnTimeout. It starts the test method in a separate thread, joins with the specified limit, calls thread.interrupt() on timeout, and then throws TestTimeoutException in the caller thread.
• JUnit 5’s org.junit.jupiter.api.extension.Timeout extension uses an ExecutorService to run the test invocation, interrupts the task’s thread on timeout, and fails the invocation with TestTimeoutException. The extension is applied per test invocation, so it works the same for dynamically generated tests (@TestFactory).
• When the timeout fires, the test instance’s lifecycle methods that run after the test method (@After in JUnit 4, @AfterEach/@AfterAll in JUnit 5) are **not** invoked for that invocation because the test is considered failed before the after‑hooks can run.
• JUnit 4’s TestWatcher (or any RunListener) receives testFinished after the test method execution (including the timeout interruption) and before the exception propagates further, so the listener sees the failure.

Likely explanation for observed delay

The TestTimeoutException can appear **after** the test method’s logical end because:

• Thread interruption is asynchronous; if the test code is in a blocking operation that does not check Thread.interrupted() (e.g., certain I/O, Object.wait without a timeout, or a synchronized block waiting on a lock that never becomes available), the thread may continue past the timeout point.
• Scheduler latency means the main thread that throws the exception may not regain control immediately after the interrupt, especially on heavily loaded systems.

Verification steps (minimal)

1. Create a test that sleeps longer than the timeout and logs timestamps before the sleep, after the sleep (if reached), and in an @After/@AfterEach method.
2. Run the test with JUnit 4 (@Test(timeout = 100)) and JUnit 5 (@Timeout(100)) and observe:
   • Whether the after‑hook runs (it should not).
   • The timestamp of the TestTimeoutException relative to the after‑hook log (if any).
   • If you replace Thread.sleep with a blocking I/O that ignores interruption, note any extra delay before the exception appears.
3. For JUnit 5 dynamic tests, repeat the same with a @TestFactory returning a stream of DynamicTest instances; the timeout behaves per invocation.

Missing diagnostic detail

If you are using a custom TestWatcher or RunListener and need to know exactly whether testFinished is called **before** or **after** the TestTimeoutException is caught by your test‑class try/catch, let me know which hook you are inspecting so I can confirm the ordering for your specific setup.