Why is BDD one of the most misunderstood concepts?

As I once tweeted, “BDD starts with collaboration, not automation”. Although its output is usually an automated test, its initial purpose is to create a shared understanding.

This is exactly what many people confuse it with – they focus on its output at the end, the automation of acceptance tests. While in reality Behavior Driven Development (BDD) covers a variety of aspects from collaboration through automation. These are: 

1. BDD starts with collaboration between the triad – customer, developer, and tester – to foster a common understanding of a requirement (e.g. feature / story / business rule) 
2. The understanding alone may be sufficient, but the collaboration typically results in an artifact that records the understanding clearly and unambiguously.    
3. The artifact does not have to be in a particular format. The triad decides what is the best way to express the understanding.   
4. The artifact can be used as a test that a system has the desired behavior. With the current prominence of DevOps, there is an emphasis to craft the artifact as an automated test. However, the test can be run manually.

Below I would like to talk about a few of the common misconceptions:

Misconception #1: BDD and Gherkin syntax are the same

The behavior of a requirement is often described as “Given some initial state, when some action or event occurs, then there is some output or a change in state”. So artifacts are often written in Gherkin using a Given/When/Then template. However, some frameworks use different styles. For example, Fit/FitNesse uses just tables. The understanding of other requirements, such as business rules, could be described as “This input should produce this output”, so an Excel spreadsheet is often used as the artifact. While the format is not prescribed, the shared understanding is almost always established using examples that illustrate requirements. The examples include sets of values which demonstrate where differences in behavior occurs, such as boundary values.  

Misconception #2: BDD is done by the testers only

One of the members of the triad could create the artifact alone, but without sharing it with the other members, the essential joint understanding is missed. A tester could create a test using the Gherkin syntax and automate it, but that is just doing testing, not collaborating. I was at one company where the developers were creating their tests in SpecFlow (C# automation of Gherkin). But the product owner was never shown those tests. That is just doing another form of testing, not BDD.     

Misconception #3: BDD, ATDD, and TDD are the same 

The collaboration of the triad in BDD and ATDD (Acceptance Test-Driven Development) results in an artifact that represents an unambiguous test of a requirement. The only difference between the two is the BDD emphasizes creating scenarios (Given/When/Then) which become the tests and ATDD focuses on creating testable scenarios. The tests in BDD/ATDD may take hours or days to pass, depending on the size and complexity of a requirement. TDD involves mainly the developer (or developer/tester) in creating tests that describe the responsibilities for the internal parts of an implementation. Tests are created, code is written, and tests pass in a minute or a few minutes.  

Misconception #4: BDD is a testing method

Since tests are a tangible output of BDD, these tests are often conflated with the process. The tests represent the shared understanding of the requirements, which is achieved through BDD.

What misconceptions have you heard about BDD?

Let us know on Twitter or LinkedIn with #SpecFlow.