Behavior Driven Development (BDD)

Liz Keogh answered this question for us, It is exactly “BDD is the art of describing behaviour by giving examples.” we can say.

BDD has a concept that tests the behaviour 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 writt en 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 behaviour 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 behavioural 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 behaviours they want to see in the system.
• The developer asks questions based on their understanding of the system, while also writing down additional behaviours needed from a development perspective.
• The testers decide on which system behaviours 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 behaviour.

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

Originally published at https://medium.com on June 17, 2021.