What is BDD?
Liz Keogh answered this question for us, It is exactly “BDD is the art of describing behavior by giving examples.” we can say.
BDD has a concept that tests the behavior of your product rather than testing your code.
Same time; In the early 2000s, there was a small clique of people from the XP community who were exploring better ways to do TDD (Test Driven Development). Dan North named this BDD (Behavior Driven Development). He is now considered the father of BDD.
BDD vs TDD
The codes written while performing Test Driven Development are written, read, and understood by the developer. These written tests are not required by anyone other than the developer. If your tests pass, it’s okay.
While doing Behavior Driver Development, it is expected that the tests you write can be understood and read by everyone, not just the developer who wrote the test. Not only the developers but also the teams working with many stakeholders should be able to monitor and follow the behavior of the product you produce in a company. These teams can sometimes be managers, sometimes sales and product analysts. Therefore, my entrepreneurs need to specify the BDD factor in their software teams.
When Is BDD Preferred?
Since BDD creates our behavioral tests, you need to be in control of the whole process related to the product.
If your manager is warm to the BDD and constantly conveys the information to you in this direction if many teams are working on the same ground with the product, it is an expected situation that your product will change with the process; Although it may seem like a waste of time, in the beginning, it will be the only factor that keeps the process alive in the long run.
Three Amigos
The people in charge of defining the requirements (business analysts / agile product owners) sit down with programmers and testers and discuss features (similar to agile stories) to be implemented.
- The business person specifies behaviors they want to see in the system.
- The developer asks questions based on their understanding of the system, while also writing down additional behaviors needed from a development perspective.
- The testers decide on which system behaviors the acceptance tests will be written.
These three amigos (business persons, developers, testers) come up with examples of how the software should behave, and write them down as Cucumber Features and Scenarios. Thereafter the software development happens following the principles of ATDD (Acceptance Test Driven Development) and TDD (Test Driven Development).
Feature Mapping
- Define a feature or story, or pick one from the backlog.
- Understand what actors are involved in the story.
- Break the feature into tasks to identify the main flows.
Identify examples that illustrate a principle or variant flow. Ask questions like: “But what if…”; “what else could lead to this outcome”; “what other outcomes might happen”; and use the answers to create new examples. Use rules to explain and give context to your examples.
- Rinse and repeat for other rules and examples.
- Create Executable Specifications: automate the main high-level flows with pending steps.
BDD with Cucumber and Gherkin
For BDD, you can use Frameworks CucumberJS and CucumberSelenium. It allows you to test your Gherkin forwarding. Gherkin also conducts your tests by reading them with what you have written.
Gherkin
Gherkin (DSL) allows our BDD tests to be written with CucumberJS and CucumberSelenium on the product in a format readable by teams working at the same denominator. Although the extension of these files is usually .feature, the written file is called gherkins. At Gherkin, we have the concepts of features and scenarios. Thanks to these concepts, we will be able to comfortably manage product behavior.
The scenario in Gherkin should be a one-sentence summary of the work done by that file. In short, it conveys the result obtained from the combination of action and result.
Given, When and Then
Given is used to indicate the initial state of our test created in the specified scenario. When contains real events that will be executed in our test. Then is used to reveal the result of our test.
As best practices, it is important to keep the steps small at this stage. Depending on your scenario, sometimes you don’t need to use all the steps.
Gherkin Test Example
Here we can see that the code tells us how the product will behave, not how it will work. Even if Google changes the UI, our Gherkin file will be able to continue its functionality.
You can find more information about the steps in the CucumberJS and CucumberSelenium documents.
I will end my article by giving a few examples.
Background: User navigates to Company home page
Given I am on the “Company home” page on URL “www.momentumsuite.com”
Then I should see “Log In as Employee” message
Scenario: Successful login
When I fill in “mail” with “xxx”
And I fill in “password” with “xxx”
And I click on the “Log In” button
Then I am on the “Dashboard” page on URL “www.momentumsuite.com//en/automate-projects”
And I should see “automate” message
And I should see the “Log out” button
Here I used the Background feature. In its testing phase, it applies the action up to the background feature.
If we go through the same example, let’s see how it is written in the change of mail and password at this time.
Background: User navigates to Company home page
Given I am on the “Company home” page on URL “www.momentumsuite.com”
Then I should see “Log In as Employee” message
Scenario: Successful login
When I fill in “mail” with <mail>
And I fill in “password” with <password>
And I click on the “Log In” button
Then I am on the “Dashboard” page on URL “www.momentumsuite.com//en/automate-projects”
And I should see “automate” message
And I should see the “Log out” button
Examples:
| mail | password | | yyy | zzz |
In the example here, we have seen that we can export data from outside so that more than one test can be run and we will not be changing data on the code every time.
You can check the more detailed usage method from the document.
