Liz Keogh has wonderful 30 minute video on the Skills Matter site: “10 Years of Doing BDD All Wrong”. As one of the driving forces behind behaviour driven development (BDD) she’s allowed to be critical, especially as she’s critical of herself, and has many positive, constructive things to say, too. There is one particularly valuable insight that I came away with and that I wanted to pass on here: you don’t need BDD for the majority of your tests.

More specifically, you don’t need BDD scenarios for requirements that are more easily expressed with traditional unit tests, or with other lowish-level code tests. Liz described BDD’s sweet spot as the “complicated” realm, where situations need analysis from experts. The BDD scenarios are an essential vehicle for having a conversation with the non-coding experts during the coding, when the exact logic needs to be clarified. And they’re useful after that, too, when someone needs to come back and review the code (perhaps for maintenance, or for analysis of a new phase of work).

But if the situation is routine or obvious then BDD isn’t a good tool, she said. Examples of this are checking a routine calculation, or confirming login. These are situations when the logic and outcome are obvious, and a more efficient approach is to write low level unit tests, or something close to that.

I’m pleased that I’ve heard this from one of the originators of BDD. I’ve seen BDD scenarios used too often in the recent past—often by teams who are working with code that’s difficult to test from the inside. Liz says the level of the tests should be related to the complexity of the requirement. And by implication, the code should be capable of being tested at all levels. If it’s not, perhaps it should be changed to be so.

There are many more insights there, too. Go take a look.

Photo by Dave Gilbert