Delivering value is essential to stay in business. But although it is honorable to write well-structured, reliable code with good test coverage, you could still fail to meet requirements altogether. This is where Behaviour-Driven Development (BDD) comes to the rescue.
BDD gets you to think in terms of “behaviour” instead of “test”. It encourages the delivery of prioritized, verifiable business value by providing a common vocabulary that is understandable by business and development folks.
Focus on delivering business value
The objective of a development team is to deliver software that matters. So it’s important that the customer defines his need before anyone starts jumping into design and getting caught up in code implementation. The business and development teams should know which features must be developed first. Clarifying requirements up-front will drive architecture, design and development efforts in the same direction. This way, we increase the commitment and buy-in of the everyone involved.
Have the conversations
BDD works by defining behaviour and it is focused on learning by encouraging questions, conversations, creative exploration and feedback. Having conversations is essential as it cannot be replaced by any process or tool. Business people and developers must work together so bridging the communication gap is essential. A ubiquitous language based on the business domain enables domain experts and developers speak without ambiguity.
Speak a common language
The language used by most BDD tools follows the Gherkin format. Feature files, describing acceptance criteria of the features (use cases, user stories) don’t necessarily have to be written in English as Gherkin supports more than 40 human languages. So because communication is everything in the BDD approach, we must bridge the gap between business and development folks. But do the two groups differ?
- Business people are focused on building the right product. They have roles like: product owners, domain experts and human factor engineers.
- Development people are focused on building the product right. They have roles like: architects, developers, testers and database administrators.
BDD intends to produce a vocabulary that is accurate, accessible, descriptive and consistent. The idea is that the words you use influence the way you think about something.
Document the requirements as code
A requirement consists of plain text description of the user story and scenarios. The requirements must be specific enough that everyone knows what’s going on. A typical template structure looks like:
- As a [role]
- I want a [feature]
- So that [business value]
Has many scenarios:
- Given a [context]
- When an [event happens]
- Then an [outcome should occur]
The readable behaviour-oriented specification can be turned into implemented, tested and production-ready code. And managing requirements as code documents the system which is inline with agile principles.
Automate the testing process execution
Once you got the scenarios written following the template, you’re ready to automate the testing process. Tools like Cucumber (Ruby) and Specflow (C#) can automatically convert the natural language scenarios into executable test code. The tests get automatically named after the “given”, “when” and “then”, so no more confusing naming. The only work remaining then is to implement the different parts as reusable step definitions.
You can use BDD to complement TDD for unit testing and for integration testing. You can run the generated BDD stories/scenarios as part of your automated continuous integration/continuous testing pipeline. And that’s the beauty of it, because it’s not a tool but an approach, you can use in the way it will benefit you the most.