JUnit 4 offered @Test(expected = SomeException.class) and the ExpectedException rule for exception tests. How do you express the same intent in JUnit 5, and why is the replacement considered stronger?

## The three JUnit 4 idioms and their problems **1. `@Test(expected = X.class)`** — the terse form. Its flaw is scope: the assertion is "somewhere in this method an `X` escaped". A test intending to prove that `submit()` rejects a duplicate can pass because the *fixture* threw `IllegalStateException` for an unrelated reason, so the code under test may never even have been called. It also cannot inspect the exception at all. **2. try/fail/catch** — the manual form: ```java try { order.submit(); fail("expected IllegalStateException"); } catch (IllegalStateException expected) { assertEquals("...", expected.getMessage()); } ``` Correct, but verbose, and the failure mode when someone forgets the `fail(...)` line is a test that passes when nothing throws — silently asserting nothing. **3. `ExpectedException` rule** — declarative: ```java @Rule public ExpectedException thrown = ExpectedException.none(); @Test public void rejects() { thrown.expect(IllegalStateException.class); thrown.expectMessage("already submitted"); order.submit(); } ``` Expectations must be declared **before** the throwing call, which reads backwards, and any statement after the throwing call is unreachable — so post-assertions are impossible. Declaring the expectation after the call yields a puzzling failure. The rule was deprecated in JUnit 4.13 in favour of `Assert.assertThrows`, which JUnit 4.13 added precisely because the Jupiter design proved better. ## The Jupiter replacement ```java static <T extends Throwable> T assertThrows(Class<T> expectedType, Executable executable) ``` `Executable` is a functional interface whose `execute()` may throw anything, so a lambda containing checked-exception calls compiles without wrapping. The method: - fails if nothing is thrown, - fails if something of the wrong type is thrown (and reports what it actually got), - otherwise **returns** the exception, typed. That return value is the whole ergonomic win: assertions about the exception are ordinary assertions after the fact, in normal reading order. ```java var ex = assertThrows(ResponseStatusException.class, () -> controller.get("missing")); assertEquals(404, ex.getStatusCode().value()); assertTrue(ex.getMessage().contains("missing")); ``` ### Exact type versus subtypes `assertThrows(RuntimeException.class, ...)` is satisfied by any subclass — often what you want, sometimes too loose. `assertThrowsExactly` requires the precise class. Prefer the exact form when the *type itself* is the contract (for instance, distinguishing `IllegalArgumentException` from a custom subclass callers switch on). ### Related assertions - `assertDoesNotThrow(executable)` — makes "this must not blow up" explicit and, on failure, reports the exception rather than letting it propagate as an error. - `assertAll(...)` — groups independent assertions so all failures are reported, useful when replacing JUnit 4's `ErrorCollector` rule during the same migration. - `assertTimeout` / `@Timeout` — replaces `@Test(timeout = ...)`. ## Migration mechanics Converting `@Test(expected = X.class)`: 1. Remove the attribute from `@Test`. 2. Identify the *single* statement that should throw — this is the step that finds bugs, because it forces you to say which line you meant. 3. Wrap it in `assertThrows`, and move any setup out of the lambda. 4. Add message/cause assertions if the old test had `ExpectedException.expectMessage`. Converting `ExpectedException`: 1. Delete the `@Rule` field. 2. Turn `thrown.expect(X.class)` into the first argument, `thrown.expectMessage(s)` into an assertion on `ex.getMessage()`, `thrown.expectCause(matcher)` into an assertion on `ex.getCause()`. 3. Put the throwing call in the lambda, keeping it minimal. A useful review rule: the lambda should contain **only** the call under test. If a lambda has three statements, the test has drifted back to the `expected=` problem where any of the three could be the thrower. ## Pitfalls - Wrapping too much code in the lambda reintroduces the scoping weakness. - Ignoring the return value throws away the main benefit; asserting on the message is usually the difference between "it failed" and "it failed for the right reason". - Asserting on message text alone is brittle when messages are user-facing or localised — assert on type plus a stable field or error code where one exists. - `assertThrowsExactly` is not a drop-in for `assertThrows`: switching to it can break tests that legitimately throw subclasses.