Behavior-Driven Development
However, around four years ago,[13] a group of Agile practitioners starting rocking the boat. The key observation seemed to be that it’s perfectly possible to write high quality, well-tested, reliable, and maintainable code, and miss the point altogether. As software developers, we are employed not to write code, but to help our customers to solve problems. In practice, the problems we solve pretty much always fit into one of three categories:
Help the customer make more money.
Help the customer spend less money.
Help the customer protect the money they already have.
Around this recognition grew up an evolution of TDD focused specifically around helping developers write code that matters. Just as TDD proved to be a hugely effective tool in enhancing the technical quality of software, behavior-driven development (BDD) set out to enhance the success with which software fulfilled the business’s need.
The shift from TDD to BDD is subtle, but significant. Instead of thinking in terms of verification of a unit of code, we think in terms of a specification of how that code should behave—what it should do. Our task is to write a specification of system behavior that is precise enough for it to be executed as code.
Importantly, BDD is about conversations. The whole point of BDD is to ensure that the real business objectives of stakeholders get met by the software we deliver. If stakeholders aren’t involved, if discussions aren’t taking place, BDD isn’t happening. BDD ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access