You want a JUnit 5 extension that records the outcome of every executed test method — passed, failed, aborted, or skipped — into your own report. Which extension interface gives you that, and what exactly are its callbacks?

## What TestWatcher is for Most Jupiter extension callbacks fire *around* a test: before it, after it, when a parameter needs resolving. None of those tell you cleanly how the test turned out. `TestWatcher` is the interface whose entire job is to receive the **result** of a test method after the engine has decided it — for custom reports, flaky-test tracking, screenshots on failure, publishing metrics, or annotating an external system. ## The four callbacks ```java public interface TestWatcher extends Extension { default void testDisabled(ExtensionContext context, Optional<String> reason) {} default void testSuccessful(ExtensionContext context) {} default void testAborted(ExtensionContext context, Throwable cause) {} default void testFailed(ExtensionContext context, Throwable cause) {} } ``` All four are `default` no-ops, so an implementation overrides only the ones it cares about. **`testDisabled(context, Optional<String> reason)`** — the test was *not executed* because an `ExecutionCondition` returned a disabled result (that includes `@Disabled`, `@EnabledOnOs` and friends, and your own conditions). The `Optional` holds the reason string the condition supplied, if any. Note the shape: a skip is not a failure and carries no throwable. **`testSuccessful(context)`** — the test method completed without a failure being recorded. **`testAborted(context, Throwable cause)`** — the test *started* and then bailed out at runtime rather than failing. The canonical cause is `org.opentest4j.TestAbortedException`, thrown when a runtime precondition inside the body was not met. Reporting-wise, aborted sits between skipped and failed: work was done, the verdict is inconclusive. **`testFailed(context, Throwable cause)`** — the test failed. The `cause` is the throwable that caused it, typically an `AssertionFailedError` from an assertion or any exception escaping the test. Exactly one of the four is invoked for each test method the engine processes, so a watcher can safely increment counters without double counting. ## What you get from the ExtensionContext The `ExtensionContext` passed in is the context of the test that just finished. Useful accessors: `getDisplayName()`, `getUniqueId()`, `getTestClass()` and `getTestMethod()` (both `Optional`), `getTags()`, `getRequiredTestClass()` / `getRequiredTestMethod()` for the non-optional forms, and `getExecutionException()` (which mirrors the `cause`). That is enough to key a report row, group by tag, or find the source method with reflection. ## Which nodes trigger it `TestWatcher` observes **test methods** — `@Test` methods and each invocation of a `@TestTemplate`, so a `@RepeatedTest` with five repetitions produces five callbacks, and a parameterized test produces one per argument set. It is *not* invoked for containers: test classes and `@Nested` classes do not produce watcher callbacks, and neither does a test that never executes because its enclosing container failed — for example when a class-level `@BeforeAll` throws, its tests are never started, so no per-test callback arrives. If you need a genuinely complete picture of the run, including container failures, that belongs at the launcher level with a `TestExecutionListener` rather than in an extension. ## Registration and timing Register a watcher the usual ways — `@ExtendWith(MyWatcher.class)` on the test class, a static `@RegisterExtension` field, a common test interface, or automatic registration via the `ServiceLoader` mechanism so it applies to the whole suite. Class level or higher is the sensible placement: a watcher that only exists for one method rarely earns its keep, and registration high in the hierarchy is what makes suite-wide reporting work. The callbacks run **after** the test has finished and after its after-each lifecycle callbacks, which matters if your watcher wants to capture state produced during teardown — by then teardown has already run. ## A worked shape ```java public class ResultRecorder implements TestWatcher { private static final List<String> ROWS = Collections.synchronizedList(new ArrayList<>()); @Override public void testSuccessful(ExtensionContext c) { row(c, "PASSED", null); } @Override public void testFailed(ExtensionContext c, Throwable t) { row(c, "FAILED", t.toString()); } @Override public void testAborted(ExtensionContext c, Throwable t) { row(c, "ABORTED", t.toString()); } @Override public void testDisabled(ExtensionContext c, Optional<String> reason) { row(c, "SKIPPED", reason.orElse("no reason given")); } private static void row(ExtensionContext c, String status, String detail) { ROWS.add(c.getUniqueId() + "|" + status + "|" + Objects.toString(detail, "")); } } ``` Note the synchronised collection: with parallel execution enabled, watcher callbacks arrive from multiple threads. ## Choosing between TestWatcher and the alternatives - Need the **outcome** of individual test methods, in-process, with access to the extension context (stores, tags, the test instance's class)? `TestWatcher`. - Need something to run **after** every test regardless of outcome, and possibly to fail the build? An after-each callback — a watcher cannot influence results. - Need the whole run, including containers, plans and the summary, or need it to work across engines? A launcher-level `TestExecutionListener`. - Need to *react to* a thrown exception and possibly swallow or rethrow it? A test-execution exception handler, which sits in the failure path itself rather than observing it afterwards.