The whole point of acceptance tests and BDD is to make sure that your application works as expected, not only your code. Acceptance tests, then, should not be written by developers but by the business itself. Of course, you cannot expect that managers and executives will learn how to code in order to create acceptance tests, but there is a bunch of tools that allow you to translate plain English instructions or behavioral specifications into acceptance tests' code. Of course, these instructions have to follow some patterns. Behavioral specifications have the following parts:
- A title, which describes briefly, but in a very clear way, what use case the behavioral specification covers.
- A narrative, which specifies who performs the
test, what the business value is, and what the expected outcome is.
Usually the format of the narrative is the following:
In order to <business value> As a <stakeholder> I want to <expected outcome>
- A set of scenarios, which is a description and
a set of steps of each specific use case that we want to cover.
Each scenario has a description and a list of instructions in the
Given-When-Thenformat; we will discuss more on this in the next section. A common patterns is:Scenario: <short description> Given <set up scenario> When <steps to take> Then <expected outcome>
In the next two sections, we will discover two tools in PHP that you can use in order to understand behavioral scenarios and run them as acceptance tests.