BDD is a process, not just an automation framework. The team should follow and apply BDD process for all software development activities. Writing executable specification during story refinement or sprint planning. Before starting implementing the features. Try to automate ES in sprint if possible.
BDD = discover + formulation + automation
The BDD process moves through three phases—discovery, formulation, and automation where the acceptance criteria are transformed into acceptance tests that are later automated. The process begins in the discovery phase, where the Product Owner or Product Manager creates acceptance criteria as part of writing a story or feature.
https://www.serenity-dojo.com/bdd-from-start-to-finish1625655063824
As a backlog item moves closer to implementation, the formulation phase solidifies acceptance criteria by creating acceptance tests (Executable Specification – ES). Initial acceptance criteria are often described with ambiguous, general terms. The formulation phase resolves these ambiguities by turning the scenarios into detailed acceptance tests that are specific, clear, unambiguous examples of behaviour
The automation phase automates the acceptance tests, so they can be run continuously and validate that the system always supports the new behaviour.
- Gherkin keywords order in a Scenario should be: Given-When-(And)-Then-(But)
- Avoid multiple given-when-then in single scenario
- Write in a declarative way, not Imperative: Scenario steps should describe the business and feature description, not UI interactions like clicking links and entering data in form fields.
- Scenario should be atomic, data for each scenario should be independent.
- Overuse of scenario outlines. Do not use Scenario Outline if there is only 1 dataset in the Example
- Step definition should be reusable
- Step name should reflect to what it does so that anyone can easily understand when we can use that step
- DONOT Calling another step in step definition: Calling steps from step definitions is not supported; this is by design. The best way to achieve composition and reuse, is to use the features of your programming language. If you want to combine several actions into one step, extract individual (helper) methods and call these methods from your step definition.
- Step name should start with lower case as in feature file it stands behind Gherkin keyword
Cucumber Anti-Patterns
- Bad collaboration
- Write the feature files after you have written the code
- Business people create scenarios in isolation. Devs or testers writing scenarios without talking to business people
- Scenario is too high level
- Describing actions using the personal pronoun
Reference Links:
https://support.smartbear.com/cucumberstudio/docs/tests/best-practices.html
https://cucumber.io/blog/bdd/cucumber-antipatterns-part-one/
https://cucumber.io/blog/bdd/cucumber-anti-patterns-part-two/
Step Up Automation 