Looking at BDD from the perspective of requirements engineering

February 22, 2011 | 1 Minute Read
This post was originally posted on my old blog.

A listener to the Hansleminutes Podcast about Executable Specifications was asking me:

All of the examples of BDD I’ve seen follow mostly the happy path with only an occasional nod to the unhappy path and don’t seem to go into as many corner cases and essentially code coverage as unit tests too, but this feels incomplete.

Gojko also recieved the question and published an extensive answer on his blog: Duplication between BDD and Unit tests


1279316 question mark

My answer was the following:

One approach how I look at BDD is, that I do not look at it as an extension for Testing/TDD but rather an extension to requirements gathering.
The crucial thing from this perspective is to develop a shared understanding by working out concrete examples. Don't yet think about tests, ask you what would I write down in a specification, so that everybody understands what the system should do.
These are then the scenarios that you should strive to automate.
Later in the project you may add more scenarios to cover special cases/edge cases but it is not the goal of BDD to completely cover all possible paths through the system. For non-trivial systems this is usually not possible, so the challenge is to find the key-example that provide the most value regarding the shared understanding.

Of course this BDD approach is orthogonal to unit-testing/TDD. Here you rather strive for combinatorial completeness in the sense of code coverage. follow me on twitter, I need some friends :-)