Tuesday, July 27, 2010

BDD is more than “TDD done right”

BDD is more than just doing TDD right. Beginners in TDD struggle to understand that TDD is really about design and not testing. Similarly, newcomers to BDD may find it challenging to appreciate that BDD is also about collaboration between stakeholders and not just software behavior. You will find discussions on the internet on “BDD is TDD done right”. That’s certainly true, but there is much more to BDD. We will soon look at the additional value BDD offers, but first let us list why people think BDD is just TDD done right. 
  1. TDD captures behavior or intentions just like BDD. You write a test case upfront to capture a behavior. However, the vocabulary is all test based so this is confusing. BDD fixes this by using the right vocabulary. Therefore, BDD is still TDD – but better. 
  2. TDD captures low-level requirements (usually at the class/method level). BDD captures high-level requirements. Therefore, BDD is still TDD - but at a higher level.
  3. BDD and TDD result in a suite of tests that we can run as a regression suite. Therefore, BDD is still TDD.
What then does BDD offer that is not in TDD? The value is largely in the collaborative process for defining requirements and the grammar and structure used for capturing them.
BDD captures requirements as user stories. A story has two parts – a narrative and scenarios. A requirement is not complete until it has both. We write Stories in BDD with a rigid structure. We write a narrative using a Role/Benefit/Value grammar and scenarios using a Given/When/Then grammar. Following a rigid structure like this can help adoption of a common vocabulary that leads to unambiguous requirements.

However, the benefit goes beyond that.

The crucial value that BDD offers is the process for creating the user stories. User stories are developed collaboratively by the key stakeholders – the Product Manager (or customer or Business Analyst), the QA resource and the developer. This level of collaboration results in:
  1. Developing features that truly add business value.
  2. Preventing defects rather than finding defects. Think how much easier it is to write code when you have scenarios that exemplify the positive and negative behaviors and make the intention transparent to the programmer.
  3. Bring QA involvement to the forefront. This is great for team dynamics because in many agile processes QA personnel feel ignored.
  4. Define executable, verifiable and unambiguous requirements.
  5. Provide a better definition of “DONE” for agile development. 
However, the benefit goes beyond that.

BDD also helps you write “Software that matters”. What does this mean? Think of it as writing just enough code to meet a business requirement. You are probably thinking, “I could do that with TDD too”. Consider this. As you are writing Junit tests cases, is a stakeholder (Product Manage/Business Analyst/QA resource) with you? Probably not. Have you ever written code (probably excellent code, perhaps even following TDD practices), that was not required? Probably yes. You may not have shipped it, but you probably wrote it, found no use for it and deleted it. That is a waste. When you follow BDD, you are less likely to do this. You will reduce waste.

How can we write “Software that matters”?

The best way to do that is to leverage BDD and TDD. Here is an approach:
  1. Write requirements as user stories using the BDD grammar/structure. Do this collaboratively with the key stakeholders.
  2. Enter the User Stories (feature + scenarios) in a BDD tool.
  3. Write code to map the User Stories to tests.
  4. Write production code using TDD to make the tests pass. 
As you can see, BDD is not just TDD done right. You could use just the vocabulary of BDD to improve TDD but that would be like using only some of the benefits that BDD has to offer us. When we use the the strengths of both these techniques we will have “Software that matters” along with “Software that works”.
That is the promise of BDD.


Anonymous said...

Very well defined.

Anonymous said...

Excellent explanation.

Igor Zevaka said...

Totally agree. The "T" is often over-emphasized, leading to false assumption that TDD is a testing technique, whereas the second "D" is far more important. TDD is a development technique, with certain regression benefits.

J. B. Rainsberger said...

Well written, thanks. I so enjoy meeting people who can reason well: if BDD = TDD + ??, then BDD must do what TDD does, and a dash extra. Wonderful, and annoyingly rare.

Anonymous said...

Well Written

ping pong said...

Great article.

I have a question, as follows:

Given a user story includes both feature and scenario, does feature and scenario have one-to-one or one-to-many relationship.

Thanks in advance.

Saiful Islam said...

"BDD captures high-level requirements" what does mean for?

Anonymous said...

figures. If you essential to be cooked with that entropy
is asked. No purchasing place ordain not
be overpriced, and when neutering the distinctness of your place, wait swing off the
smoothen of the call up itself. A honored online merchandiser.
Additionally, reckon for the try feeling Chanel Handbags Outlet Chanel Outlet Hermes Outlet Celine Outlet Burberry Handbags Kate Spade Outlet Polo Ralph Lauren
Jimmy Choo Shoes Online Marc Jacobs Outlet Nike Air Max Jimmy Choo Shoes Online Toms Outlet
CHI Flat Iron Website
Gucci Outlet Burberry Outlet Christian Louboutin Outlet Hermes Birkin Marc Jacobs Outlet Mac Cosmetics Nike Free Christian Louboutin Shoes Marc Jacobs Handbags Outlet
Celine Bags Oakley Sunglasses Cheap CHI Flat Iron Website Oakley Sunglasses Outlet CHI Flat Iron Toms Outlet a breathable bag (not pliant).
Try to write mass releases is that all but folk
equal. The internet can be antitrust what the players are easier
to output up the inopportune business enterprise course of action erst more formerly you've pioneer out many
harmonic reps until you awareness you require to hire.
location are