Cucumber-JVM and JUnit 5: Dependency Injection State Management

Direct Answer

Cucumber-JVM—not the JUnit 5 engine—owns the DI container lifecycle. After each scenario (pass or fail), Cucumber core invokes ObjectFactory.stopScenario() in a finally block, which disposes scenario-scoped objects. JUnit 5’s @AfterEach does not run per Gherkin scenario, so it cannot be relied on for DI cleanup. Mixing cucumber-picocontainer and cucumber-spring on the same classpath is unsupported: both register an ObjectFactory, causing ambiguous container selection and potential duplicate step-definition instantiation. Choose one container for all step definitions in a test run.

Confirmed Behavior

• Single ObjectFactory per runtime. Cucumber loads exactly one ObjectFactory implementation. Including both PicoContainer and Spring modules makes which one wins non-deterministic.
• Per-scenario disposal via stopScenario(). The Cucumber runtime (not JUnit) calls this after every scenario, even when a step throws. PicoContainer drops its scenario-scoped instances; Spring closes the child ApplicationContext created for that scenario.
• JUnit 5 lifecycle is orthogonal. The cucumber-junit-platform-engine maps each scenario to a dynamic test node. @BeforeEach/@AfterEach fire once per test template (the feature file), not per scenario.

Likely Explanation (Version-Sensitive)

• PicoContainer is lightweight: it creates a fresh container per scenario, injects step-definition classes, and discards them in stopScenario().
• Spring via cucumber-spring builds a parent ApplicationContext from @ContextConfiguration and a child context per scenario. stopScenario() closes the child context, invoking @PreDestroy and DisposableBean callbacks.
• Cross-container state is invisible. Beans in the PicoContainer scenario scope cannot be @Autowired into Spring beans, and vice versa, unless you manually bridge them (not recommended).
• Versions matter. Cucumber-JVM 7.x (Jakarta namespace) and Spring 6+ behave differently from 6.x/5.x (javax namespace) regarding context caching and close semantics. Pin both versions and test failure paths.

Practical Verification Steps

1. Add a step-definition class with a field annotated @PreDestroy (Spring) or a no-arg close() method (PicoContainer) that logs a unique marker.
2. Run a scenario that deliberately fails (e.g., throw new AssertionError()).
3. Confirm the marker appears exactly once after the failure—proving stopScenario() executed.
4. Run the same scenario twice; assert shared mutable fields reset to defaults on the second run to detect cross-scenario leakage.
5. Check dependency tree: mvn dependency:tree | grep -E 'cucumber-picocontainer|cucumber-spring'—only one should be present.

Recommendation

Use one DI container:

• If you need full Spring integration (profiles, @Autowired, test slices), use cucumber-spring alone with @ContextConfiguration.
• If you only need lightweight scenario-scoped state sharing, use cucumber-picocontainer alone.

Do not mix them for the same scenario state.

One Diagnostic Detail Needed

What are your exact Cucumber-JVM and Spring Framework versions? The child-context close behavior and Jakarta/javax namespace shift between major versions can change whether stopScenario() reliably disposes beans on failure.