5 exercises on the vocabulary of test-driven and behaviour-driven development — the red-green-refactor cycle, Given-When-Then, acceptance criteria and design-first thinking.
Key patterns
red-green-refactor → the TDD cycle
write a failing test → test-first
Given-When-Then → BDD scenarios
acceptance criteria → conditions for "done"
drive the design / spec out behaviour
0 / 5 completed
1 / 5
Explaining test-driven development, a mentor says: "The cycle is ___ — first make a failing test, then make it pass with minimal code, then clean up." Which phrase names the TDD cycle?
Red-green-refactor — the TDD cycle:
Test-driven development follows a short, repeating loop, named for the test-runner colours:
Red — write a failing test first; it fails because the behaviour doesn’t exist yet
Green — write the minimal code to make the test pass (do the simplest thing)
Refactor — with a passing test as a safety net, clean up the design without changing behaviour
Collocations:
"the red-green-refactor cycle / loop"
"go red, then green"
"refactor under green" — only refactor while tests pass
The other options are real cycles from other domains (PDCA, git workflow, ops) but are not the TDD loop. The defining rhythm of TDD is fail first, then pass, then improve.
2 / 5
A TDD purist insists: "In strict TDD you must ___ a ___ test before you write any production code." Which pair completes the rule?
Write a failing test — the first move in TDD:
The cardinal rule of test-driven development is test-first: you write a failing test that describes the behaviour you want, watch it fail for the right reason, and only then write the code to satisfy it.
"write a failing test" / "start with a failing test"
"watch it go red" / "see it fail first"
"make the test pass" — the next step
Why fail first? A test that has never been seen to fail might be asserting nothing — watching it go red proves it actually exercises the new behaviour. A passing test written first proves nothing; deleting or skipping tests is the opposite of TDD. The canonical phrasing is write a failing test.
3 / 5
A BDD scenario is structured: "___ a logged-in user, ___ they click delete, ___ the item is removed." Which three keywords structure a behaviour scenario?
Given-When-Then — the BDD scenario structure:
Behaviour-driven development describes features as scenarios in the Given-When-Then format (Gherkin syntax, used by Cucumber, SpecFlow, Behave):
Given — the precondition / starting context ("Given a logged-in user")
When — the action / event ("When they click delete")
Then — the expected outcome ("Then the item is removed")
Collocations: "write a Given-When-Then scenario", "the Given step", "a feature file", "And / But" to chain steps.
Note the cousin: the unit-test analogue is Arrange-Act-Assert (AAA) — same three-part shape (set up, do, check) but in test code rather than business-readable scenarios. Both are valid; the business-readable one BDD uses is Given-When-Then.
4 / 5
In refinement, a product owner says: "For this story to be done, it must meet the ___ — the agreed conditions that define success." Which term fits?
Acceptance criteria — the conditions that define "done":
Acceptance criteria are the specific, testable conditions a user story must satisfy to be accepted as complete. They turn a vague story into something verifiable.
"meet the acceptance criteria" / "the story satisfies its acceptance criteria"
"define / write acceptance criteria"
"acceptance test" — a test that checks a criterion
contrast: the Definition of Done applies to every story; acceptance criteria are per-story
In BDD, acceptance criteria are often expressed directly as Given-When-Then scenarios, so the criteria become the automated acceptance tests. The distractors are unrelated: edge cases are unusual inputs, code coverage is a test metric, and merge conflicts are a version-control issue.
5 / 5
A senior engineer praises TDD: "Writing the test first forces you to ___ the ___ from the caller’s point of view — you design a clean API before implementing it."
Drive the design — TDD as a design tool, not just a testing one:
A key claim of TDD is that writing the test first lets the test drive the design: because you use the API before it exists, you shape it for the caller’s convenience, ending up with cleaner, more decoupled interfaces.
"drive the design" / "tests drive out the design"
"design emerges from the tests" / "emergent design"
"spec out the behaviour" — describe what it should do before building it
"the test is executable specification"
The bigger idea: in TDD and BDD, tests are not only verification — they are a specification written first. You spec out the behaviour, the spec drives the design, and the passing tests document it. The distractors describe later stages (build/merge/deploy), not the design-shaping effect of writing tests first.