Do @BeforeEach and @AfterEach run around each case produced by a JUnit 5 @TestFactory method? Explain the lifecycle and how you would get per-case setup and teardown.

## The actual execution order For a class containing a `@TestFactory` method: 1. `@BeforeAll` 2. `@BeforeEach` — **once** 3. the factory method is invoked and returns nodes 4. every generated case runs, in order, with **no** lifecycle callbacks between them 5. `@AfterEach` — **once** 6. `@AfterAll` So the whole set of generated cases sits *inside* one `@BeforeEach`/`@AfterEach` pair, in the same test instance. There is one test-class instance for the factory (under the default per-method lifecycle), and every generated case runs against that same instance. Note that with a lazily consumed `Stream`, steps 3 and 4 interleave — a node is produced, executed, then the next is pulled — but that does not change the lifecycle: no callbacks fire between cases either way. ## Why it works this way Dynamic cases are not methods. Jupiter's method-level lifecycle is defined in terms of test *methods* it discovered and the instance it created for them. A dynamic case is a display name plus an `Executable` created at runtime; there is no method to reflect on, no parameters to resolve, no annotations to inspect. Rather than invent a half-working lifecycle, JUnit documents plainly that lifecycle callbacks and the corresponding extension callbacks are **not** executed for dynamic tests. This also explains other absences people trip over: per-case timeouts from `@Timeout` on the factory apply to the factory method as a whole; extensions that intercept test method invocation do not intercept dynamic case bodies. ## What this means for state Shared state across generated cases is the practical hazard. A factory that builds a service in `@BeforeEach` and generates twenty cases against it gives all twenty cases one service instance. If case 3 leaves it dirty, case 17 may fail — and it will fail *only* when the whole factory runs, never when you reproduce it alone (which you cannot do easily anyway, since dynamic cases are not individually selectable before the run). Symptoms to recognise in an interview answer: order-dependent failures inside one factory, failures that vanish when the input list is filtered, a case that passes in isolation but fails in sequence. ## Getting per-case setup and teardown **1. Build it into the executable.** The cleanest approach — each case creates and disposes of what it needs: ```java @TestFactory Stream<DynamicTest> perCaseFixture() { return inputs.stream().map(input -> DynamicTest.dynamicTest( "case " + input, () -> { Service service = new Service(); // per-case setup try { assertTrue(service.handles(input)); } finally { service.close(); // per-case teardown } })); } ``` **2. Wrap with a helper.** Factor the try/finally into a function that takes the body and returns a wrapped `Executable`, so every case gets the same treatment and the intent is explicit. **3. Reset between cases.** If the shared fixture is expensive to rebuild, reset it at the *start* of each case's body rather than the end, so a case that throws does not poison the next. **4. Reconsider the tool.** If every case genuinely needs full isolation and lifecycle, dynamic tests may be the wrong mechanism. Statically declared tests keep per-method instances, the full lifecycle, extension support, and individual selectability. Choose dynamic generation when the *set of cases* must come from runtime data, not merely to loop over a known list. ## Interaction with @Nested A `@TestFactory` inside a `@Nested` class behaves the same way: the outer and nested `@BeforeEach` both run once, outside-in, around the factory invocation — not around each generated case. ## The sentence to say out loud "Lifecycle callbacks wrap the factory method, not the generated cases; dynamic cases share one instance and one fixture, so per-case setup has to live inside each case's executable — and if I need real isolation per case, that is a signal to use statically declared tests instead."