Design a custom TestExecutionListener that seeds and cleans up per-test data. Which callbacks do you implement, how do you register it without breaking defaults, and what are the pitfalls?

## Skeleton ```java public class SeedDataTestExecutionListener implements TestExecutionListener, Ordered { @Override public int getOrder() { return 4500; // after TransactionalTestExecutionListener (~4000) } @Override public void beforeTestMethod(TestContext testContext) { var ctx = testContext.getApplicationContext(); var repo = ctx.getBean(WidgetRepository.class); Widget w = repo.save(new Widget("seed")); // stash state for later callbacks in the TestContext, NOT a field testContext.setAttribute("seededId", w.getId()); } @Override public void afterTestMethod(TestContext testContext) { Object id = testContext.getAttribute("seededId"); if (id != null) { testContext.getApplicationContext() .getBean(WidgetRepository.class) .deleteById((Long) id); } } } ``` Register it: ```java @SpringBootTest @TestExecutionListeners( listeners = SeedDataTestExecutionListener.class, mergeMode = MergeMode.MERGE_WITH_DEFAULTS) class WidgetServiceTest { /* ... */ } ``` ## Key design decisions ### 1. Which callbacks Override only what you need — all methods are `default`. For per-test data use `beforeTestMethod`/`afterTestMethod`. If you only care about the pass/fail of the body, use `afterTestExecution` and read `testContext.getTestException()`. ### 2. Getting dependencies A `TestExecutionListener` is **not a Spring bean** — it's instantiated by the framework via a no-arg constructor. You therefore cannot `@Autowired` into it. Obtain collaborators from `testContext.getApplicationContext().getBean(...)`. The context is the same cached context the test uses. ### 3. Ordering vs the transaction Decide whether your writes should live inside the test's transaction: - **Inside (auto rollback):** order **> 4000** so `TransactionalTestExecutionListener` has already opened the tx. No manual cleanup needed if the test is `@Transactional`. - **Outside (survives across methods, or the test isn't transactional):** order accordingly and clean up explicitly in `afterTestMethod`. ### 4. State must not live in fields Spring creates **one** listener instance and reuses it for the whole class (and it may be shared). Storing per-test state in instance fields is a concurrency/leakage bug. Use `TestContext.setAttribute/getAttribute`, which is scoped to the current test context. ### 5. Registration options - `@TestExecutionListeners(..., mergeMode = MERGE_WITH_DEFAULTS)` on the class/base class — explicit and local. - Global auto-registration via `META-INF/spring.factories` under the `org.springframework.test.context.TestExecutionListener` key — applies everywhere without annotations (good for a shared test module). ## Pitfalls checklist - Forgetting `MERGE_WITH_DEFAULTS` -> `@Autowired`/`@Transactional`/`@Sql` break. - `@Autowired` in the listener -> always null; use `getBean`. - Instance fields for per-test state -> leakage; use TestContext attributes. - Exceptions in `beforeTestMethod` abort the test and may skip parts of setup — make it robust. - `after*` callbacks run in **reverse** listener order, and afterTestMethod still runs even if the test failed — write idempotent cleanup. - Non-transactional tests: your data won't roll back automatically; clean up explicitly. - Assuming `prepareTestInstance` is per-method — with `@TestInstance(PER_CLASS)` it isn't. ## When to prefer alternatives For pure SQL fixtures prefer `@Sql`; for event capture use `@ApplicationEvents`; write a custom listener only when you need cross-cutting behaviour those built-ins don't cover (metrics, external system reset, tenant setup).