If we follow the incorrect example:
Given the value entered in the Number text box is not numerical
When the Form is submitted
Then an error message “Please enter a numerical value” appear
Given the User is logged in ← Condition
And the value in the Number text box changes ← Trigger
When the value in it is not numerical ← Condition? Trigger?
Then an error message “Please enter a numerical value” appears
This further blurs the lines of precondition and trigger, which actually voids the purpose of a clearly defined BDD format.
To explain this point further, if we don’t care about what goes where as long as it is comprehensible, why not just throw away the 'Given' clause entirely?
So, what exactly is the behavior we’re testing here?
Is it the behavior of entering a First Name? Entering an Email? Entering a password? Or is this testing the behavior of submitting sign up details?
What about the validity of these fields entered? Granted, these questions could be easily answered by a simple conversation with the team. After all, story cards act as a pointer for conversations.
However, imagine these conversations at scale, for every acceptance criteria of every story. Ideally, acceptance criteria should be written as unambiguously as possible, so that we reserve conversation time for more complex matters. There are bigger fish to fry.
The When clause should only contain a single trigger, and the Given clause should list all the conditions that have an impact to that trigger.
Given I’m at the sign up form
And all these mandatory fields are entered
The clear distinction between these two examples is that the right example has a clear trigger, i.e. submission of the form; with a clear precondition, i.e. the fields are validated; the wrong example has a sequence of events in the trigger.
Again, at first glance, this looks right, and frankly, it is not hard to write acceptance tests for this. Yet, there is a simpler, and better way of writing the same scenario:
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.