The Process of Behavior Driven Development
How is BDD different from TDD (Test-Driven Development)?
BDD is an evolution of TDD, and different in many ways. In Test-Driven Development, developers will go through four phases: they will write unit tests (which inevitably fail), develop the feature to ensure the tests pass, refactor the code to strengthen it, and then repeat this cycle until completion. In contrast, BDD development teams add ‘acceptance’ and ‘black-box’ tests to this same loop, making sure the unit responds to different behaviors. BDD also introduces shift left techniques such as Specification by Example and Example Mapping, to focus the development of the team down the right path.
Can BDD be used with manual testing?
Absolutely, and this is one of the main benefits of BDD. It is not just a tool that operates automatically, but rather a set of practices designed to help teams develop more intuitive and effective software. When used correctly, Gherkin scenarios are primarily behavior specifications that improve your team’s collaboration and accountability. As test cases, they can be used either manually or with automation.
How many Gherkin scenarios should one story have?
The simple answer is that there is no limit: it’s completely up to you. Of course, there are practicalities at play as well. A handful of rules per story is more than enough, and you shouldn’t need more than a handful of examples (up to five) per rule. If you’re getting to a point where you feel overwhelmed by the number of rules and examples needed for a story, it’s probably a sign that the story itself should be broken into smaller independent pieces.
Should you do Example Mapping for every story?
This is a good question: of course, spending 20–30 minutes Example Mapping each story might take a long time. Instead, try mapping just one or two stories to start with. This will help your team improve and to get quicker at the process. Having said this, the upfront time costs of Example Mapping are well worth it and they will save a lot of time later in the process, for several reasons. Firstly, the acceptance criteria will be clear, secondly, the tests will already be written, and lastly, your whole team will have an understanding of the story, saving you from miscommunications and inefficiencies. If you’re struggling for time, consider replacing planning meetings with Example Mapping meetings, as these will prove more useful.
What metrics should you use with BDD?
Metrics all have their pros and cons, but they can be useful for BDD. Whilst using BDD, remember that the standard testing and Agil metrics all still apply (code coverage, story velocity, etc), but you can add additional metrics such as:
- the percentage of Gherkin scenarios that get automated in the sprint
- the number of rules and examples that get “missed” during Example Mapping and must be added later
- the percentage of stories that undergo Example Mapping before the sprint
Can you use BDD with technical stories or backend features?
Of course! BDD is great for technical stories and backend features — if you can describe it, you can use it.
What further resources would you recommend for BDD?
- Automation Panda
- Cucumber
- SpecSolutions
- The Cucumber Book
- BDD in Action
Click Here to join us with Andy Knight, a BDD expert, to learn more about BDD and get any of your questions answered in this livestream!
Questions about Tools
What good tools work with BDD and Example Mapping?
There are many tools that work well with the process, a few of which are listed below.
- Cycle Automation provides a nice app with Gherkin steps out of the box, so you can automate tests without needing a programming language.
- TeamUp Labs has an online Example Mapping tool.
- IDEs from JetBrains and Eclipse provide BDD plugins
- Gherkin Syntax Highlighting in Notepad++
- Gherkin Syntax Highlighting in Visual Studio Code
- Gherkin Syntax Highlighting in Atom
- Gherkin Syntax Highlighting in Chrome
What’s the difference between Gherkin, Cucumber, and SpecFlow?
Though sometimes they seem to be used interchangeably, Gherkin, Cucumber, and SpecFlow are all very different things, though this can be confusing for beginners. Essentially, Gherkin is the name of the language itself, a line-oriented script in which scenarios can be written. Cucumber is a software tool: it is the name of the company and the test framework within which Gherkin is used. SpecFlow is a ‘port’ for Cucumber that allows you to use Gherkin files and wire them up to .NET code.
Questions about Testing
Can you use BDD for unit testing?
BDD frameworks work at their best for black-box feature testing. They can be used for unit testing, but they tend to be a bit unwieldy for code-level unit tests. In short: yes, but it’s not advisable. For more information on this, read BDD 101: Unit, Integration, and End-to-End Tests.
How long should Gherkin scenarios be?
Essentially, as short as possible. Scenarios are most effective when they are bite-sized, focusing on a single individual behavior. Any more than this risks becoming overcomplicated and inefficient, and destroying the point. There’s no hard limit, but single-digit step counts are usually ideal.
What are “step definitions” in Cucumber?
When you run a Gherkin scenario through a BDD framework as a test, each step in the scenario will be connected to a ‘step definition’. These are the methods used by the automation code to execute each step.
How do you minimize duplicate code within a BDD test framework?
The simple answer is that you need to know your steps like the back of your hand. Writing can be a slow business as you search for existing steps before creating new ones, but it’s worth the effort in the long run. Applying good coding practices is key, remembering that you’re essentially writing software as you create test automation. Reuse steps wherever you can, refactor existing steps and make sure to enact pair programming or mob programming when writing scenarios.
What’s the best way to write Gherkin scenarios so that they can be automated?
The best way to write scenarios if you’re not familiar with the automation process yourself is to use pair programming with automation engineers and write the scenarios together. If this isn’t possible, make sure that you read and search feature files to become familiar with existing steps, otherwise, you risk your Gherkin steps being unusable.
What if you find yourself with large test gaps and many steps that aren’t reusable?
This is a relatively common issue for people, especially those working in separate teams, and it can be difficult to resolve. There are two paths: refactoring, or starting over. To guide your decision between these paths, ask yourself the following questions:
- What are your goals for testing and automation?
- What’s your overall quality and testing strategy?
- What parts of the code base are salvageable?
- What parts of the code base should be removed?
- If you started again from scratch, what would you do differently to make sure the same problems don’t reoccur?
Click Here to join us with Andy Knight, a BDD expert, to learn more about BDD and get any of your questions answered in this livestream!