When would you implement JUnit 5's BeforeEachCallback/AfterEachCallback extension interfaces instead of just writing @BeforeEach and @AfterEach methods in the test class, and what do you gain?

## Two ways to run code around a test JUnit Jupiter offers a user-facing lifecycle (`@BeforeAll`, `@BeforeEach`, `@AfterEach`, `@AfterAll` methods in the test class) and an extension lifecycle (`BeforeAllCallback`, `BeforeEachCallback`, `AfterEachCallback`, `AfterAllCallback` implemented by a separate class and registered on the test). They can run the same code; they differ in reuse, position and capability. ## What annotated methods are good at Fixture code that only makes sense for this class. `orderService = new OrderService(repo, clock);` reads best right next to the tests that use it. There is no registration, no indirection, no extra file; a newcomer sees the whole setup in one place. If exactly one test class needs it, an extension is over-engineering. ## What extensions are good at **Reuse across classes without inheritance.** The classic pre-JUnit-5 way to share setup was an abstract base test class. Java has single inheritance, so two orthogonal concerns (a database transaction and a stubbed HTTP server) cannot both be base classes; teams end up with a deep, brittle `AbstractIntegrationTest` hierarchy that every test drags along. Extensions are composed: `@ExtendWith({DatabaseExtension.class, MockServerExtension.class})`, or better, folded into a single meta-annotation like `@IntegrationTest` that carries both. Adding a concern later touches one annotation, not a hierarchy. **Position in the lifecycle.** Extension callbacks sit *outside* the annotated methods: `BeforeEachCallback` runs before the class's `@BeforeEach`, and `AfterEachCallback` after its `@AfterEach`. That ordering is exactly what infrastructure needs — the extension opens the transaction, the test class's own setup inserts fixture rows inside it, the extension rolls it back afterwards. A base-class `@BeforeEach` cannot guarantee that relationship as cleanly once inheritance and nesting are involved. **Deterministic composition.** Multiple extensions wrap like nested try/finally blocks: before callbacks in registration order, after callbacks in reverse, with ordering controllable via `@Order` on `@RegisterExtension` fields. Two base classes cannot express that at all. **Richer context.** A callback receives an `ExtensionContext`, which exposes the test class and method, display name, tags, the unique id, the parent context, and a namespaced store for state scoped to the test or the container. Annotated methods see only what the class already holds (they can inject `TestInfo`, but they cannot participate in scoped storage or read a parent context). **Access to the rest of the extension model.** Once you are writing an extension you can also implement parameter resolution, exception handling, conditional execution or test-instance post-processing in the same class, so the concern stays in one place. **Distribution.** Extensions ship in a library and can be auto-discovered; that is how Mockito's `MockitoExtension`, Spring's `SpringExtension` and Testcontainers' integrations work. Base classes cannot be published as reusable behaviour in the same way. ## The programmatic middle ground `@RegisterExtension` on an instance or static field gives you an extension configured in code: ```java @RegisterExtension static WireMockExtension server = WireMockExtension.newInstance().options(...).build(); ``` This keeps the reuse and lifecycle position of an extension while letting the test class pass parameters — a middle ground between a declarative `@ExtendWith` and hand-written setup. Static fields participate in the class-level (`BeforeAll`) callbacks; instance fields in the per-test ones. ## Costs to weigh Extensions add indirection: reading a test no longer shows all the setup. Overuse produces "magic" suites where nobody can explain what state a test starts in. Guidelines that keep it healthy: - Extract to an extension on the **third** duplication, not the first. - Give the extension a name that states its effect (`RollbackTransactionExtension`, not `DbHelper`). - Keep it single-purpose and side-effect-visible; document what it leaves in the store or injects. - Prefer a composed meta-annotation so a test class declares intent (`@IntegrationTest`) rather than a list of mechanisms. ## The decision in one line If the code is about *this* class's subject under test, write `@BeforeEach`. If it is about the *environment* many classes need, and especially if it must wrap those classes' own setup or compose with other environmental concerns, write an extension.