In JUnit 5 (Jupiter), how do you plug a reusable extension such as the Mockito or Spring test integration into a test, and which declaration sites are valid for the @ExtendWith annotation?

## One plug-in mechanism instead of two JUnit 4 had two extension points that did not compose. `@RunWith(SomeRunner.class)` was powerful but exclusive: one runner per class, so you could not have the Spring runner and the Mockito runner at the same time. `@Rule`/`@ClassRule` composed but could only wrap statement execution. Jupiter merges both ideas into the `org.junit.jupiter.api.extension.Extension` marker interface, which sub-interfaces such as `BeforeEachCallback`, `ParameterResolver`, `TestInstancePostProcessor` and `ExecutionCondition` extend. An extension is just a class implementing one or more of those callback interfaces; registering it means telling Jupiter to add it to the extension registry for some scope. ## Declarative registration with @ExtendWith `@ExtendWith` is the declarative path — you name a **class**, Jupiter creates the instance for you. Valid targets: 1. **Test class** — the extension participates in every test in that class. Because Jupiter honours annotation inheritance, an abstract `IntegrationTestBase` annotated with `@ExtendWith` passes it to every subclass, and `@Nested` inner classes inherit from the enclosing class. 2. **Test method** — scoped to that one method; class-level callbacks such as `BeforeAllCallback` cannot fire meaningfully there because the class-level phase has already happened. 3. **Field or parameter** (since Jupiter 5.8) — mostly for `ParameterResolver`s that should only apply to one injection point. 4. **Another annotation** (meta-annotation) — this is how `@SpringBootTest` and `@DataJpaTest` work: they are ordinary annotations that themselves carry `@ExtendWith(SpringExtension.class)`, so the user never types `@ExtendWith`. `@ExtendWith` is `@Repeatable` and its value is an array, so `@ExtendWith({A.class, B.class})` and two stacked annotations are equivalent. ## Instantiation and deduplication Jupiter instantiates a declaratively registered extension via its **default (no-arg) constructor**. That is the whole reason `@RegisterExtension` exists: with `@ExtendWith` there is no place to pass a port number, a builder result, or a preconfigured client. The extension class must be concrete, and it must not be `private`. Jupiter also **deduplicates**: the same extension implementation registered more than once inside one registry hierarchy is only applied once. So a base class with `@ExtendWith(SpringExtension.class)` plus a subclass repeating it does not double the callbacks. This is why meta-annotations can be layered freely. ## Ordering, briefly Extensions are registered in a deterministic order: inherited/class-level declarations first (outermost class down), then the order in which `@ExtendWith` annotations appear, and programmatically registered extensions after them. "Before" callbacks then run in registration order and "after" callbacks in reverse — an onion, like nested try/finally blocks. Relying on the exact interleaving of unrelated extensions is fragile; if order matters, use `@Order` on programmatically registered fields. ## Choosing between the two styles Use `@ExtendWith` when the extension needs no configuration — Mockito, Spring, your own logging or clock-freezing extension with sensible defaults. Use `@RegisterExtension` when you must build the instance, or when the test body needs to talk to it (for example asking a WireMock extension for its randomly assigned port). Both end up in the same registry; the annotation only decides who constructs the object.