Behaviour driven development (BDD) is a software development process, its purpose is to communicate early in the development process to ensure the team is building the right thing. In BDD teams create simple scenarios on how an application should behave from the end user’s perspective.
The goal of implementing BDD testing is to improve collaboration between key stakeholders, such as product managers, product owners, business analysts, developers and testers by writing test scenarios in a domain specific language called Gherkin.
Three Amigos:
What is 3 amigos?
The Three Amigos meeting is a formal opportunity to communicate about the transition from user stories to scenarios to drive automated testing. It is meant to happen before development starts, part of a good test first approach.
It involves a smaller group unlike a sprint refinement or planning meetings, happens on demand, and generates tests. But also, there is no reason to limit these meetings to just three people or to hold only one such meeting. Continually refine the scenarios and collaborate with everyone to best understand how to talk about, develop, and test the application.
Acceptance Tests (ATs):
Cucumber is a BDD tool which helps facilitate the use of an easy-to-learn language called Gherkin. In Python the Gherkin-style language can be implemented using different tools like Behave, Freshen and Lettuce and In C sharp using Specflow and in Java, Ruby in Cucumber.
Doing this allows people who are non-technical, but have knowledge of the requirements, to write the scenarios that make up our ATs. This is a powerful thing when it comes to capturing the required behaviour. People in the BDD community refers to this as a ‘Ubiquitous Language'(it is a common language used by developers and users for common specification for the domain that they are working on. It is a rigorous language in which domain can be explained easily.) and then the tests can be run using a parser which will allows us to match the Gherkin steps.
Writing Gherkin:
It is preferable that the first draft of any feature be written by, or with, a “domain expert” such as a product owner or a business analyst. Then the developer(s) and tester(s) will go over the scenarios, refining the steps for clarification and increased testability. The result is then reviewed by the domain expert to ensure the intent has not been compromised by their reworking.
This cycle is repeated until everyone involved is satisfied that the Scenarios accurately describe what is wanted in a testable manner.
Features:
Cucumber tests are written in terms of “Features”. Each feature consists of one or more “Scenarios”.
Scenarios:
You can have any number of scenarios for a feature. If you are having lots and lots of scenarios in one feature, then you might actually be describing more than one feature. When that happens, it is recommend splitting up the document into separate Feature definitions. (The definition of “lots and lots” here is subjective, and it’s up to you determine when it’s time to split up a feature.)
The first line of Scenario definition provides a short description of what the scenario is intended to cover. If you can’t describe your scenario in a single sentence (and not a run-on sentence), then it’s probably trying to cover too much, and should be split into multiple scenarios.
That is followed by some combination of “Steps”— lines that begin with the keywords Given, When, and Then (typically in that order).
You can have many lines that use the same keyword (e.g., Given there is something followed by Given I have another thing). To increase the readability, you can substitute the keywords And or But (e.g., Given there is something followed by And I have another thing).
In general, any Given step line should describe only one thing. If you have words like “and” in the middle of a step, you are probably describing more than one step, and should split it into multiple steps.
Cucumber features are best served by consistency. Don’t say the same thing in different ways — say it the same way every time.
