Behavior-driven development (BDD) is something I'm currently using at work as part of our testing suite. I recently gave a presentation about the benefits and process involved with BDD. This post is a consolidation of that information and some takeaways from that process.
What BDD is
- It's not about testing, it's about discovery, communication, collaboration, and examples.
- It's a process for sorting out requirements.
BDD produces a suite of tests but it's not the primary focus of the process. The real value from BDD should be from the collaboration between stakeholders. It also provides a great feedback loop that can be used to iterate on features.
For this reason, I think BDD and TDD can go hand in hand. BDD tests are great at testing the general requirements of a project, while other unit tests are good at testing the nitty gritty implementation details.
What BDD isn't
- It's not a replacement for manual testing
- It's not a replacement for load, penetration, other kinds of tests
If I haven't said it enough already, BDD's primary benefit is shared understanding between the product team members. Manual testing is still beneficial as well as other kinds of tests.