- 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.
- 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.
- BDD and TDD result in a suite of tests that we can run as a regression suite. Therefore, BDD is still TDD.
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:
- Developing features that truly add business value.
- 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.
- Bring QA involvement to the forefront. This is great for team dynamics because in many agile processes QA personnel feel ignored.
- Define executable, verifiable and unambiguous requirements.
- Provide a better definition of “DONE” for agile development.
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:
- Write requirements as user stories using the BDD grammar/structure. Do this collaboratively with the key stakeholders.
- Enter the User Stories (feature + scenarios) in a BDD tool.
- Write code to map the User Stories to tests.
- Write production code using TDD to make the tests pass.