TDD and BDD Language

The red-green-refactor cycle is the core loop of Test-Driven Development. "Red" means you write a failing test first. "Green" means you write the minimum code needed to make that test pass. "Refactor" means you improve the code structure without changing its behaviour, keeping all tests green. This cycle ensures every line of production code is justified by a test.

A Gherkin scenario is a structured, plain-language description of a software behaviour using the keywords Given, When, and Then. "Given" sets the initial context, "When" describes the triggering action, and "Then" states the expected outcome. For example: "Given I am logged in as an admin, When I delete a user account, Then the account should be removed from the system." The language is intentionally non-technical so both developers and business stakeholders can understand it.

In TDD standups, developers typically say "I wrote tests for the payment service and made them pass." In BDD standups, the language shifts toward business outcomes: "I completed the scenario for successful checkout and collaborated with the product owner to define the edge cases." BDD encourages teams to describe work in terms of features and user value, not just unit tests and code coverage.

Common phrases include: "line coverage," "branch coverage," and "path coverage." Reviewers might say "this function lacks branch coverage for the error path" or "we have 87% line coverage but the critical payment flow has no edge-case tests." The term "coverage gap" refers to untested code, while "coverage ceiling" describes a project's target threshold, such as "we enforce 80% coverage as a quality gate."

Mutation testing automatically introduces small bugs (called "mutants") into your code to verify that your tests actually catch them. A mutant that is not caught by any test is called a "surviving mutant," indicating a weakness in the test suite. Developers say things like "our mutation score is 74%" or "we need to kill the surviving mutants in the validation module." Tools such as Stryker and PITest are commonly referenced in these discussions.

The "should" naming convention structures test names as a statement of expected behaviour: "should return null when the user is not found" or "should throw an error when the input exceeds the maximum length." This makes the test output self-documenting. An alternative pattern is "given_when_then" in the function name itself, such as "givenExpiredToken_whenValidating_thenThrowsAuthException."

BDD discovery sessions use phrases such as "let's explore the scenario where…", "what would happen if…", "can we define the acceptance criteria for…", and "who is the primary actor in this story?" Facilitators often ask "what does 'done' look like?" to surface implicit expectations. The phrase "example mapping" describes the technique of using coloured cards to capture rules, examples, and open questions.

A test double is an object that stands in for a real dependency during testing. Specific types include: a "stub" (returns canned responses), a "mock" (verifies interactions), a "fake" (a lightweight working implementation), and a "spy" (records calls without replacing behaviour). Developers say "I'll stub the external API call" or "we need to mock the database connection to avoid hitting real infrastructure in unit tests."

A "flaky test" is one that produces inconsistent results without any code changes — passing sometimes and failing others. Teams describe this as "non-deterministic" or "unreliable." Common causes discussed include timing issues ("this test has a race condition"), order dependency ("it only fails when run after the auth tests"), and external state ("it depends on a shared database fixture"). Fixing flaky tests is often called "stabilising the test suite."

The test pyramid is a model recommending a large base of unit tests, a smaller middle layer of integration tests, and a narrow top of end-to-end tests. Teams say things like "we're too top-heavy — most of our coverage is in E2E tests, which makes the suite slow" or "we should push this logic down to unit tests." The anti-pattern of relying too heavily on E2E tests is called an "ice cream cone" and is used as a warning in architecture discussions.