Proper acceptance criteria
Standard
One Scenario should only have one result
It has two results since it has two When-Then
.
Separating When-Then
into two scenarios would create one result for each scenario.
This is easy to trace because each failure points to a unique problem.
It is concise and more focus on a particular scenario.
💡 Advisory Note:
The Cardinal Rule of BDD: One Scenario, One Behavior!
1 behavior -> 1 example -> 1 scenario -> 1 test -> 1 result
Deliver it in declarative form, enough to have descriptive steps
This is a declarative form, BUT too vague and ambiguous.
Now take this another example, a complete opposite of the previous one. This is written in an imperative form and it is too descriptive.
Focus on the part of "what" and "why". 'What' you want and the 'why' to your development team. Minimize from using the technical jargons
This example, have the right balance to be declarative and at the same time has clear steps.
Make use of the data table to display unique examples
Make use of the third person and be consistent throughout the scenario
This example, have a clear persona.
Remove ambiguity
It has an ambiguous result, clarify it like this:
It explicitly tells you what exactly happens. The example above makes the readers reduce the potential assumptions.
Make it consistent
Take note of these steps and it's intention.
Given
steps should use past or present-perfect tense because they represent an initial state that must already be established.When
steps should use the present tense because they represent actions actively performed as part of the behavior.Then
steps should use the present or future tense because they represent what should happen after the behavior actions.
Resources
Last updated