This challenge is about deciding when to use a BDD specification for a feature, and when not:
I see the benefit of using Gherkin for user-facing end to end tests, but a lot of the examples here seem to be testing components or smaller code units, not just user interface. This can lead to duplication between different types of tests. If something can be covered equally well with a unit test or Given-When-Then, it’s not easy to decide where to put it. How do you choose if something should be a unit test or a BDD spec?
Members of our community posted ideas on the topic of choosing between developer-oriented unit tests and business-facing given-when-then specifications, when some feature can in theory be covered by both.
As a special treat for this challenge, instead of me posting the usual summary and my ideas, the phenomenal Dave Farley responds with a video.
Dave is the author of the incredibly influential Continuous Delivery book, and recently started posting weekly video tips on improving software delivery. I strongly suggest signing up for his channel! Watch Dave’s response to our challenge below, and subscribe to his Continuous Delivery YouTube channel directly on YouTube.
Dave posted an excellent response, illustrating it with rulers, tape measures, fence posts and even a few expletives that had to be bleeped out. He presents a compelling argument on why duplication between unit tests and BDD specs is sometimes perfectly fine, and you do not have to choose between the two at all. To echo Dave’s key message, “Test all the F***ing time!”.