Glob Patterns
A glob pattern in @Gherkin2JUnit lets a single marker class drive many feature files — one generated test class per feature, all extending the same marker.
Source: examples/common-use-cases/example-6 on GitHub.
What this demonstrates
@Gherkin2JUnit("specs/**/*.specb")matches all.specbfiles recursively- One marker class → one generated test class per discovered feature
- All generated classes extend the same marker
- Hierarchical layout (
specs/cart/,specs/user/) is preserved
Directory layout
src/test/resources/
└── specs/
├── cart/
│ ├── AddToCart.specb
│ └── Checkout.specb
└── user/
├── Login.specb
└── Registration.specb
src/test/java/.../glob/
└── AllFeatures.java ← single marker class with the glob pattern
The marker class
The marker needs nothing but the glob pattern:
@Gherkin2JUnit("specs/**/*.specb")
public abstract class AllFeatures {
}
The pattern above is resolved from the classpath root. Prefix it with ./ to anchor matching at the marker class's own package directory instead — e.g. @Gherkin2JUnit("./**/*.specb") discovers every feature file sitting alongside the marker and below, without repeating its package path. The same ./ prefix works for individual file paths too (e.g. @Gherkin2JUnit("./Cart.specb")).
What gets generated
AllFeatures.java
├→ AddToCartScenarios.java (from specs/cart/AddToCart.specb)
├→ CheckoutScenarios.java (from specs/cart/Checkout.specb)
├→ LoginScenarios.java (from specs/user/Login.specb)
└→ RegistrationScenarios.java (from specs/user/Registration.specb)
Each generated class is independent and extends AllFeatures.
Implementing the steps
Glob discovery is orthogonal to how you implement steps — do it however you like: directly on the marker, in a concrete subclass, or grouped into domain interfaces. When many discovered features share step vocabulary, pulling the implementations into interfaces the marker implements keeps things tidy — see Organizing Steps into Interfaces.
Run it
cd examples/common-use-cases/example-6
mvn test