Resources

BDD and executable specifications

Specifications a person and a test runner can both read, and the collaboration that makes them worth the syntax.

9 resources3 from official documentationThe craft

Behaviour-driven development gets adopted as a file format and then blamed for not helping. That is the wrong order. The value was always in the conversation that produces the examples — a business person, a developer and a tester agreeing on what “declined card” means before anybody writes code — and the Gherkin file is a record of that agreement, not a substitute for it.

A scenario and the code behind it. The sentence is the shared artefact; the binding is private to the test suite.

The test for whether BDD is working on your team is simple: has a non-programmer ever read a scenario and corrected it? If yes, the scenarios are earning their overhead. If no, you have added an indirection layer between your tests and your test code and gained nothing, and plain test methods with good names would serve you better.

A scenario is working when

It is written in the language of the business, not the interface.
Somebody outside the team could read it and spot a wrong rule.
It describes one behaviour, with one reason to fail.
It survives a redesign of the screen it happens to be about.

It has gone wrong when

Steps are click, type and see.
A scenario has fourteen steps and three Thens.
The step definitions are a pile of near-duplicates.
Nobody but the automation engineer has opened the file in a year.

The syntax is the cheap part

Gherkin takes an afternoon to learn. Getting three people with different jobs into a room to argue about an edge case, regularly, is the expensive part and the part that produces the benefit. Teams that buy the tool and skip the meeting reliably conclude that BDD does not work.

The practice

4 entries

Cucumber: behaviour-driven development
Official docs

The canonical explanation of BDD as a collaboration practice first and a tool second. Start here, before writing a single feature file, and read the pages on example mapping and on the anti-patterns.
cucumber.io
Introducing BDD
Essay

Dan North's original 2006 article, in which BDD is invented mostly to fix the fact that people kept writing bad unit tests because the word “test” pointed them the wrong way. Short, and explains a lot of the vocabulary's shape.
dannorth.net
Example Mapping
Essay

The twenty-five minute meeting that produces scenarios worth automating: a story, its rules, an example per rule, and the questions nobody can answer yet. The most directly useful practice in this whole category.
cucumber.io
Gherkin reference
Official docs

The syntax itself: Given, When, Then, backgrounds, scenario outlines, data tables, and the localisations. Worth skimming once so you know what exists before inventing a convention that already has a keyword.
cucumber.io

The tools

3 entries

Cucumber
Official docs

The original implementation and still the reference, with ports across most ecosystems. Its documentation is unusually willing to tell you when not to use it.
cucumber.io
Reqnroll
Tool

The maintained open-source successor to SpecFlow for .NET teams. If you have a SpecFlow suite that has stopped receiving updates, this is the migration path.
reqnroll.net
pytest-bdd
Tool

Gherkin scenarios that run as ordinary pytest tests, so fixtures, parametrisation and the rest of the pytest ecosystem keep working. The lightest-weight way into BDD in Python.
pytest-bdd.readthedocs.io

Ours

2 entries

Open source, from the people who build QAright.

SpecReport
Ours

An HTML reporting toolkit for Reqnroll suites: living documentation that a non-programmer can actually open, generated from the run rather than maintained by hand.
github.com
SpecHygiene
Ours

Static hygiene checks for Reqnroll feature files, on NuGet. Finds unused step definitions, duplicated scenarios and the slow rot that sets in when a suite grows past what one person holds in their head.
github.com

What to take away

The meeting is the practice. The file is the receipt.Buying the tool and skipping the conversation is the standard way to conclude BDD does not work.
Write behaviour, never interface.A scenario mentioning a button will be rewritten by the next redesign, which is exactly what it was supposed to prevent.
If nobody outside the team reads them, stop.Well-named test methods cost less and do the same job.

Missing something? If there is a resource you send to every new tester on your team, tell us and we will read it. The list stays short on purpose; each entry has to earn its place, and entries that stop earning it get removed rather than left to rot.

Reading is the slow way to learn how a suite behaves. Record one against your own app, free, and watch what the report says.

Get started free See how it works