I decided to write this article because I meet different statements and opinions about BDD (Behaviour-Driven Development). I will try to summarize, where these bad reviews come from, in my opinion. Here is a handful of my thoughts.
Motivation of introducing BDD
Here, starts everything. For some reason we want to introduce BDD but whether the reason is good enough.
- Public distress
I have seen a lot of situations where a BDD was introduced for the sake of introducing it, only because “people talk about it” or it seems to be the cure for all project problems. Such extreme motivation is rare, but it is worth to realize if we don’t yield to external factors, just to be able to boast that we already have BDD in the project too.
- Test automation
“We introduce BDD because we want to automate tests” – automation doesn’t need BDD. Similarly, BDD doesn’t require automation. If we think about the very automation, then BDD will be an unnecessary overhead. Of course, properly written scenarios together with examples (as acceptance criteria) are ideal cases to automate, but you need to clearly tell yourself that automation isn’t the main goal here, more natural consequence. Now that we know how our application should work and scenarios describe its behaviour in a meaningful way, it would be a sin not to take advantage of automatic feedback after each introduced change.
- Better TDD
Developers use TDD and they have read that BDD is an extended version of TDD (Test Driven Development). Precisely, scenarios created in BDD process can feed our TDD process. However, sometimes BDD is understood only as a higher layer of requirements of TDD. It is necessary to look at goals. TDD allows you to create small increments fulfilling the requirements of the code, but in a very narrow range; developer focuses on covering low-level test as well as on the design of the interface and classes. At this point he/she doesn’t focus on whether this is exactly what the client needs, how they will use it and what may be missing in functionality. Of course, after going through the full cycle he/she can verify if the code meets the BDD scenario. It is not the same as following this process in the other way round by creating scenarios together with business, discovering and defining application behaviour – at that moment we don’t think about the code. In a BDD cycle we want to understand client’s needs as well as possible, we want to talk a common language and specify the intended effect of the application with the use of examples. It is all about communication over misinterpretation or guessing. Therefore, statement that BDD is only a better version of TDD is a gross simplification. All the more so if scenarios and acceptance criteria would be written only by developer, for developers, it’s hard to talk about BDD.
So why to use BDD?
BDD as a communication tool:
- Enables to define the business problem you want to solve – business value
- Helps to answer the question of how the problem will be solved – what behaviour we expect
- Clarifies when we consider that the program solves our problem – acceptance criteria, which become acceptance tests
- Discovers what should happen when… – helps to consider boundary and unusual situations
- Combines the points of view of all parties: business, project and verification
- Introduces a common language understood by all clients
- Helps to discover unidentified and hidden areas of requirements and business needs
Typical problems with BDD
Usually, it’s hard to write the perfect scenarios from the very beginning, when you just starting off. There are a few elements which may negatively influence the quality of those scenarios:
- Scenarios are written by one person (programmer or tester) without the participation of the business parties (product owner, business analyst, client)
- Are written with the use of technical language or a mixture of the technical and domain languages
- No explicit dictionary – we understand the same expressions differently, e.g. a term “user” appears in places where we have in mind a specific user role, which, depending on the context, makes that “user” someone else
- Contains a large number of steps, they are overgrown and complicated – granulation is too small
- Oversized assertion “Then” – it is hard to determine what is the purpose of a given example and what conditions are essential to fulfil
- Duplicated examples – we don’t want all the possible combinations of the acceptance criteria – we focus on the most important ones, which can teach us something new about created product
Through the eyes of user
Describing the scenarios, clients or product owners sometimes tend to present the requirements on the user interface level instead of focusing on the business problem. The end user sees with his/her mind’s eyes buttons, forms, drop-down menus and other graphical elements. At a later stage design is important, but BDD shouldn’t be used for modelling GUI. We want to know “how an application should work”, “how it should behave”, “how a new feature will resolve my problem”. Our task is to separate the layers of abstraction over implementation details. We are interested in process and logic.
Testers who start automation from the user interface tend to write scenarios starting with GUI. Then, an exemplary logging scenarios may look like that:
Given I enter user_name to “User name” field
And I enter my valid password to “Password” field
When I click on “Subbmit” button
Then I see label status “Logged in”
In this simple example, you can guess that it is a login functionality, but if we imagine more complicated examples with clicking buttons and filling forms, it can be hard to catch what functionality is presented in a given scenario. With the general form of the example:
Given a pair of a valid user name with valid password
When I log to the system
Then I should be properly logged in
We do not know anything about the fact whether the login process requires filling forms and clicking buttons or sending a query to the service dealing with login.
Scenarios become an unnecessary overhead
If the team starts to feel tired or bored while writing the scenario it means that something is wrong. Is the scenario interesting enough to write it down? Or maybe it is a modified version of the previous dozen? What are the acceptance criteria? Do we have interesting examples or we are satisfied with the positive ones?
It is necessary to reach team’s motivation. If the team feels there is no value in writing examples and talking about scenarios, and scenarios instead of helping begin to interfere, I would reconsider writing them. BDD is to help us understand what we want to create, what is important in a given iteration for the client and how valuable our code will be, after which our acceptance criteria become green. If we are in a place of “obvious” application area and we all know what we expect from its functionality, we don’t need anything to explore and inquire. It is sufficient to use tool tests that will be created in the process of TDD, or other. It is important to save somewhere those “obviousness” to be able to return to them in the future.
BDD – automate test tools
Many people I talk with about BDD are usually heavily focused on the used tools and acceptance criteria template or on what kind of testing framework to use to automate BDD. I also hear the opinions that the very BDD is a tool for automated testing. BDD is mainly the concept of ordering the communication process between the client and the developer team. Of course, in terms of communicating requirements process. If we forget this basic assumption and start thinking about BDD as a tool for automation, we can easily fall into a trap. Tools that implement the Gherkin syntax are as a “glue” between the specification (text, scenarios) and the code. It is a lot, yet not enough. A lot, because thanks to this “glue” we can run our specification against the application. Not enough, because it really doesn’t solve any problems with the very automation. BDD tools introduce an abstraction layer to our tests. Due to that tests can be read as a specification. If you have a problem with automated testing – with architecture, maintenance, ugly code – introducing BDD at this point can further deepen those problems, but definitely it won’t fix anything. Let’s fix problems with the tests in their root, not on the outside.
BDD without BDD
It isn’t unusual to introduce tools such as Cucumber, to the project without making the entire process of BDD or ATDD. No one will prohibit us to communicate with each other in a project via Gherkin scenarios. No one can also forbid replacing typical test cases with acceptance criteria in the form of scripted examples. Even if we don’t have a direct access to the business, or haven’t managed to reach a common scenario writing yet, it doesn’t mean that we can’t use BDD tools for communication and documentation of requirements. The key to success is to keep proper hierarchy and scenarios management at different levels. In our project, at the module level, programmers have very technical scenarios. They could be written in TDD, but it is easier to transcribe larger business logic into scenarios in that case – in a plain text, it is easier to understand it and share with the others. Product Owners have Gherkins on their level – generally, we, as testers, draw from them to write scenarios, which document the processes that go through the entire system (integration testing). This is a broad topic, and I only wanted to point out that using BDD tools without the typical BDD isn’t doomed to fail.
Also, it often happens that by using scenarios we have documented what we have, we want to pay off the technical debt and write a specification to what is already working. In the project in which I work, programmers began to write tests using the Gherkin. One day, I heard: “Oh, so this is how the Puzzling Method of Transforming Caterpillar into Butterfly works”. This was the signal for me that BDD scenarios aren’t an overhead in our project, they are needed and provide value.
In fact, BDD without BDD doesn’t necessarily indicate a problem.
Ideological use of BDD is definitely demanding and difficult. Despite of people’s scepticism, who complaint about BDD, I think that it is always worth trying and adapting technics and tools for your needs. If we understand BDD as a communication tool, there is a chance that the effort put in its introduction will be more than compensated, we will do the right software that is really needed by our client. BDD is particularly suited to Lean start up projects, where you have to learn quickly client’s needs, discover and understand the business and verify hypotheses concerning needs on a regular basis.