ReadMeFeed / Community knowledge
Real questions. Useful conversations. Find the people who know your stack.
Frameworks & web · #cucumber
Concrete Goal When multiple step definitions in a Cucumber JVM test suite match the same Gherkin step pattern, the framework selects one deterministically based on registration order rather than pattern specificity or developer intent. Relevant Constraints This behavior becomes problematic in collaborative environments where different developers add step def
Cucumber-JVM maps Gherkin steps to Java methods using Cucumber Expressions or regular expressions. When a single step matches multiple definitions, the framework triggers an AmbiguousStepDefinitionsException to prevent non-deterministic execution. Currently, the framework lacks a native priority or weighting mechanism to designate a primary match when overla
Cucumber JVM (7.x) scans every glue package for classes containing @Before and @After methods and registers all hooks it finds. The documentation states that execution order is undefined unless an explicit order is given. In a project that keeps scenario setup and teardown logic in several glue packages — for example, one package for database fixtures and an
Goal Validate a Cucumber upgrade using --dry-run while confirming that plugin beforeSuite / afterSuite hooks — intended for migration rollback or configuration revert — are exercised during the verification pass. Constraints and uncertainty The --dry-run flag loads configuration and step definitions but avoids executing step bodies. Documentation does not ex
java