behavior-driven-development

Write declarative Given/When/Then scenarios that describe business behavior, not UI steps. Keep each scenario focused on one behavior, use business language instead of technical terms, and store scenarios in .feature files rather than code comments.

TDD is a lower-level developer practice using unit tests, while BDD is a higher-level collaboration practice using acceptance scenarios. Use BDD to define what to build through shared examples, and TDD's Red-Green-Refactor cycle to implement it correctly.

Store scenarios in dedicated .feature files, not code comments. Feature files are executable by BDD frameworks like Cucumber, readable by non-technical stakeholders, and serve as living documentation, while comments are not executable.

Delete the existing code and re-derive it from a failing test rather than adapting it. Tests written against visible code pass on the first run regardless of correctness, so they cannot verify the intended behavior.

Common causes include mocking the unit under test instead of its collaborators, asserting on implementation details, over-mocking into tautologies, and vacuous assertions. Mock collaborators like databases or clocks, never the function being tested.

The documented exceptions are one-off prototypes, generated code, and configuration files. Even these should be raised explicitly with the user rather than silently assumed, and all other rationalizations are rejected.