📄️ Layered Tests from One Spec
One business specification can drive layered tests that verify its behaviour at different application layers. This example runs the same cart-pricing scenarios through direct Java calls, a Spring-managed bean, and a Spring Boot browser UI — giving you fast feedback on the business logic and broader confidence in the application from one shared specification.
📄️ Organizing Steps into Interfaces
Instead of declaring every step method on one class, group them into domain interfaces and have the marker class implement those interfaces. The generator inherits the step methods through the interfaces — no abstract declarations, no per-feature glue. The concrete test class only supplies the state the steps work on.
📄️ Concrete Mode
Concrete mode is the opt-out from the default. Instead of an abstract …Scenarios class you extend, the generator emits a concrete, directly-runnable …Test class. Unimplemented steps become failing stubs at run time, not compile errors.
📄️ JUnit Parameter Resolution
Step methods can receive parameters that JUnit fills at test execution time — both JUnit's built-in resolvers (TestInfo, TestReporter, @TempDir) and custom user-registered ParameterResolvers opted in via the @JUnitResolved marker annotation. SpecBinder's annotation processor sees the parameter on the step method declared in the marker class and propagates it through to the generated @Test (or @BeforeEach / @ParameterizedTest) method, where JUnit's resolution kicks in at runtime.
📄️ Execution Reporter
The dev.specbinder:execution-reporter module is a JUnit 5 extension that writes one JSON file per test class to the project's build output directory. You opt a feature in by annotating its marker class with @ExtendWith(SpecBinderReporter.class). Useful for CI dashboards, custom reporting, or any tooling that needs structured spec-execution data.
📄️ Playwright Traces per Step
Browser tests fail for reasons a stack trace rarely explains. This example wires