What does JUnit 5's @EnableRuleMigrationSupport annotation do, which JUnit 4 rule types can it handle, and what should replace those rules once the migration is finished?

## What a JUnit 4 rule was A *rule* was JUnit 4's composable extension point: a field annotated `@Rule` (per test method) or `@ClassRule` (per class) whose type implements `TestRule` (or the older `MethodRule`). It wrapped the test statement, letting it run code before and after, catch exceptions, or skip execution entirely. `TemporaryFolder`, `ExpectedException`, `ErrorCollector`, `Timeout` and `TestName` were the built-ins; teams wrote their own for database setup, WireMock servers, and so on. Jupiter has no rules. Its extension model is the `Extension` interface with fine-grained callbacks (`BeforeEachCallback`, `AfterEachCallback`, `ParameterResolver`, `TestExecutionExceptionHandler`, …) registered with `@ExtendWith` or `@RegisterExtension`. So a Jupiter class that still declares `@Rule` gets nothing — the field is ignored without warning. ## What migration support provides The `junit-jupiter-migrationsupport` artifact bridges a *limited* subset: - **`ExternalResourceSupport`** handles `@Rule`/`@ClassRule` fields and methods whose type is a subclass of `org.junit.rules.ExternalResource`. That covers `TemporaryFolder` and the very common home-grown `before()`/`after()` resources. - **`VerifierSupport`** handles subclasses of `org.junit.rules.Verifier`, notably `ErrorCollector`, running the verification after the test. - **`ExpectedExceptionSupport`** handles the `ExpectedException` rule. `@EnableRuleMigrationSupport` on a class is simply a composed annotation registering all three; you can also register just the one you need with `@ExtendWith(ExternalResourceSupport.class)`. Hard limits to state plainly: - Only those three hierarchies. A generic `TestRule` or `MethodRule` implementation — including most third-party rules that do not extend `ExternalResource` — is **not** supported and is ignored silently. - JUnit 4 must be on the test classpath, since the rule classes come from it. So the module cannot drop its JUnit 4 dependency while it relies on this. - The support is a compatibility layer with its own semantics; edge behaviours of a rule (statement rewriting, retry logic, exception swallowing) may not translate. ## The proper destinations | JUnit 4 | Jupiter | Notes | |---|---|---| | `TemporaryFolder` | `@TempDir` on a `Path`/`File` parameter or field | built in, cleaned up automatically, configurable cleanup mode | | `ExpectedException` | `assertThrows` | returns the exception for message/cause assertions | | `ErrorCollector` | `assertAll(...)` | reports all failures in a group | | `TestName` | `TestInfo` injected parameter | also gives tags and display name | | `Timeout` | `@Timeout` or `assertTimeout` | per method/class or per block | | `TestWatcher` rule | `TestWatcher` extension interface | direct analogue | | custom `ExternalResource` | `Extension` implementing `BeforeEachCallback`/`AfterEachCallback` | use `@RegisterExtension` when the instance needs constructor arguments | The `@RegisterExtension` form is the closest analogue to a rule *field*: you instantiate the extension yourself, so it can take configuration, and a `static` field gives class-level scope (the `@ClassRule` equivalent) while an instance field gives per-method scope. ## When to use the bridge at all It is worth it when a rule is widely used, non-trivial, and the migration must proceed anyway — you flip the classes to Jupiter now and port the rule later. It is not worth it when the rule has a first-class Jupiter replacement: converting `TemporaryFolder` to `@TempDir` is usually a smaller diff than adding migration support and leaves no JUnit 4 dependency behind. The risk of leaning on it is that it hides an unfinished migration. The module still depends on JUnit 4, the tests read as a hybrid, and new readers cannot tell which mechanism is authoritative. Treat any use as debt with an owner: track the classes that carry `@EnableRuleMigrationSupport`, and make removing it the definition of done for that module. ## Version note The annotation and the artifact belong to JUnit Jupiter 5.x and depend on JUnit 4.12+ being present. Its scope has never widened beyond the three rule hierarchies, so do not plan a migration around support that might arrive for arbitrary `TestRule`s.