Behavior-driven development (BDD) is a software development practice that is utilized by many agile software development teams—although it can be used in waterfall projects as well. Arguably, introducing BDD to a waterfall project may be the single best thing you can do if your team is not considering switching to an agile development process.
Jeffrey Davidson has put together a fantastic list of references on BDD. He’s even organized it into sections for people in a hurry, people who want to dive deep, and people who learn from videos. And he’s included a list of great BDD-thinkers to follow.
BDD is an evolution of test-driven development (TDD) but with an important distinction—it is outside-in. TDD is an approach to writing software that says first think about what you’re about to write, then think about how you would test the code—before writing it. Then write the tests and run them. They will fail, of course. The developer then writes code until the tests pass.
TDD is good because in addition to assuring that developers are writing automated tests for their code, they are thinking about it from a couple of different angles. The weakness of TDD is that developers are testing that the code works the way they intend, instead of testing that their code does what your requirements say it should do. That’s where BDD is better.
When a BA writes a use case, she writes post-conditions (and other elements) that specify how the system must behave. When she writes a user story, she writes acceptance criteria that define acceptable system behavior. Both use cases and user stories express expectations about how the system will behave in the context of enabling a user to accomplish a goal. When developers are practicing BDD, they will create tests of behavior that embody these expectations. Then they will write the code that embodies the behaviors until all the tests pass.
This approach to writing code accelerates the communication process between developers and analysts. Developers can review the documents, asking—“Is there enough information to define my tests of behavior?”
Most BDD testing frameworks generate output in human-readable format. This provides a dramatic reduction in a major source of errors—misinterpretation of requirements. As they review the requirements documents, they write out “empty” tests, defining the full body of tests that they expect to perform—an explicit statement of their understanding of the requirements. When the BA reviews this test-output, she can confirm that the requirements were communicated effectively.
Is your project using BDD? Let me know about your experiences by commenting below.
