BDD

Start by describing what the user does conversationally, then format it line by line: Given states the initial context, When describes the user action, and Then states the expected outcome. Keep each scenario focused on a single behavior in plain language.

Use BDD when building user-facing features with a clear actor, such as login or checkout flows, especially when requirements come as user stories. Use TDD instead for low-level utilities with no user, and spike-then-refactor when exploring unknowns.

Each scenario line maps to test code: Given becomes setup, When becomes the action, and Then becomes assertions. The test must fail first because the behavior does not exist yet, then implementation makes it pass.

Common anti-patterns include writing code before the scenario, using technical jargon instead of plain language, testing implementation details rather than behavior, letting scenarios and tests drift out of sync, and skipping manual validation of the user experience.

Proficiency is assessed at session start across four levels: Novice, Familiar, Competent, and Proficient. At session end, progression signals are reviewed and the updated level is recorded in the progress file under method_proficiency.BDD with the date.