Is Behavior Driven Development(BDD) just another name for Test Driven Development (TDD)? Or Is Behavior Driven Development only Test Driven Development done right?
Behavior Driven Development (BDD) and Test Driven Development (TDD) are Agile Practices that are complementary to the Scrum framework. Both are focused on improving the quality of the software product under development. That said, they approach building valuable software from different perspectives.
As Abraham Malow stated in 1966, “If all you have is a hammer, everything looks like a nail.” So is BDD really just TDD? The debate will continue long after you have read this blog post. While almost no one will debate that automating the testing of scenarios is a significant benefit over time, Dan North who is credited with conceiving BDD states that BDD does not require teams to automate the testing of scenarios. If a team decides not to automate scenario testing, they are not practicing TDD. Though they very well may be practicing Behavior Driven Development.
TDD is a test first approach that focuses on building things right. The programmer starts with a test based on an understanding of a requirement and then codes just enough to get that test to pass, optionally refactors and then creates another test based on the next requirement. This Red-Green-Refactor approach is often described as inside out because we start with the assumption that the acceptance criteria were validated by someone with business domain knowledge and we are coding just enough to satisfy the known requirement.
BDD is a technique to discover new requirements. When performing BDD, we remove that assumption of validated acceptance criteria by starting the effort with collaboration between business domain experts and the development team. By starting with a business focused collaboration, we have what is described as an outside-in approach to build the right thing. This collaboration results in an executable specification if you conform to the syntax required by one of the test automation tools. In Scrum, this collaboration could take place during Product Backlog Refinement.
One can perform BDD without implementing automation. BDD is not synonymous with Cucumber. Cucumber is an automation layer tool that can be used to automate your BDD specifications if you choose. When one automates their executable specification, they are now performing Acceptance Test Driven Development (ATDD).
When using Scrum, we understand that value is only created when a software product is delivered to the marketplace. Delivering software to the market requires attention to both building the right thing and building it right.
If we built the right thing but didn’t pay attention to building it right, we would likely face numerous challenges ranging from poor customer experience to an inability to respond quickly to marketplace changes due to technical debt. TDD is an excellent approach to eliminating the risk of not building something right and is focused on the implementation side of the work.
If we built it right but entirely missed on assumptions of what the marketplace demanded, we are likely to face problems related to lack of customer interest and poor customer experience because we didn’t understand what the customer wanted. BDD is an excellent approach to validating that we are building what our customers want and is focused on the discovery side of building out one’s Product Backlog.
TDD & BDD are excellent Agile practices that are complementary to the Scrum Framework in that they help the Scrum teams deliver quality Product Increments potentially for marketplace validation each Sprint.
I would encourage your teams to consider utilizing both ATDD & TDD with the goal of improving the value your software delivery, but if you are not ready to begin automation of your executable specifications, there is still significant value in performing BDD. From a BDD perspective, we value the business collaboration and conversation more than we value the automation. Not that there isn’t significant value in performing the automation, but we believe there is more value in the collaboration, conversation, and discovery. If you are currently automating your BDD specifications, Dan North would likely describe your efforts as TDD done right.
