What Is BDD and What Does It Mean for Testers?

Behavior-Driven Development (BDD), as its name indicates, is not a testing technique, but rather a development strategy (as well as TDD, which is Test-Driven Development). What it proposes is to define a common language for the business and the technical team members, using it at the outset of development and testing, which is why it's important for testers to understand BDD.

The Basics of BDD in Testing

BDD and TDD 

I used to think about BDD as an evolution of TDD, but then I realized that it is much more than a simple evolution. It's a different approach that solves a different problem. In TDD, the focus is on the unit test, while in BDD, the focus is testing on a higher level, functional and acceptance testing, as its aim is to comply with the business and not just with the code.

Both approaches may coexist since an acceptance test could be specified and then refined into unit tests when coding that functionality in the different layers. Perhaps a clear advantage of BDD is that the developers focus on understanding the functionality and how it works at a business level.

BDD in Agile Methodologies 

This strategy fits well in the Agile methodologies since, generally, requirements are defined as user stories. These user stories must have their acceptance criteria which are used to define acceptance tests, that can be written directly in a specific language called Gherkin.

A Common Language for Business and Tech: Gherkin 

Gherkin is a very simple language which can be written by someone who does not have a programming background, but at the same time, it can be understood by a computer program in order to use it as a test specification.

Typically, these tests will be stored in ".feature" files, which should be versioned together with the source code of the system being tested. Here's a simple example taken from Cucumber :

These files specify:

• Feature: the name of the functionality to be tested, the title of the test
• Scenario: one scenario for each test that you want to specify for this functionality
• Given: the preconditions
• When: the actions that are going to be executed
• Then: the expected result, the validations to be made

We usually have one per file and it will contain different test scenarios.

Note: Gherkin supports many languages, so although the most common is to see it in English, it can be in other languages as well.

Who writes the acceptance tests?

It depends greatly on each team, but acceptance tests can be written by the Product Owner or someone else from the team, like a tester or developer. Perhaps a good option is to do it together, at least the brainstorm, as a part of the story refinement. Then, the tester could be responsible for ensuring that the acceptance tests are well-written and have the proper coverage according to the defined testing strategy.

BDD and Testability 

The BDD approach favors system testability. I dare to say that this scheme works better with microservice architecture than with monolithic systems because the former allows adding and working on all layers independently per feature. This scheme facilitates testing as we think about the test before any line of code, thus providing greater testability.

This reminds me of the Scrum Master course I took by Peregrinus, where the instructor mentioned that in Agile, the important thing is to know how to "cut the cake."

Think of a multi-layered cake. Each layer adds a new flavor that is to be combined with the other layers.

If the cake is cut horizontally, some people may only get the crust, some a chocolate middle layer, another a layer of vanilla, or a mix of the two, etc. In this scenario, no one would get to taste the cake as it was fully meant to be enjoyed and no one could say they actually tasted the cake.

The same happens with the approach of writing a user story per component. Everything can work well separately, but upon integration, thousands of potential problems can appear.

That is why the stories are compared to a cake slice (When cut the right way, vertically!). This slice should include everything from the crust to the frosting so that you can try ("test") everything together.

That is, there shouldn't be a story like "implement XX functionality in the data access layer" because it's not business oriented.

BDD works best facilitating and promoting having a testable system, where the cake is cut well, focusing the stories towards a business functionality and implementing it with all of its layers completed.

BDD for Automating Tests 

The Gherkin language is simply text with some keywords and a bit of structure. Tools like it allow us to implement a connection layer between the test specification and the interface of the system to test, which also can be used as the steps of an automated test.

To start practicing, there's a great Google Chrome plugin called Tidy Gherkin. You can write the features in the text field above, and show what code is the necessary code to execute those steps in different languages (Java, Ruby, and JavaScript).

BDD in Action 

A good way to work with BDD might look like this (this is just one example that works for us in many projects, but it's not the only one we're using):

• Having a system architecture that allows for working in "slices," where stories are only finished when completed from end to end. The cake well cut!
• When the stories are refined, write the acceptance tests in Gherkin (a tester can do it without programming knowledge).
• At the start of the sprint, while there are no stories ready for testing, the automator (could be the tester) works on removing technical testing debt.
• Once a story is ready to be tested, perform exploratory testing in order to give early feedback and also determine if the feature and its acceptance test can be automated. If so, then implement the layer that connects the feature file with the system interface. This can be done using Cucumber with some language (Java, Ruby, etc.) and with an appropriate driver, which could be Selenium for web, Appium for mobile, or RestAssured for web services.
• Version the test code, the system code and the features with the same criteria.

What are your experiences with BDD? Let me know in the comments!

Further reading

How to Test Software, Part II: TDD and BDD