Purpose
A test case describes a testable scenario in Given/When/Then (Gherkin). Goal: unambiguity — both a human and an automated test understand what's checked and the expected result. BDD bonus: one format links requirement, check and (when automated) test code.
Structure: Feature → Scenario → Given (precondition) → When (action) → Then (expected). And/But for extras. One scenario = one idea.
Template
Feature: <capability>
Scenario: <name>
Given <state before> And <more> When <one action> Then <observable result> And <more checks>
Scenario Outline: <data-driven> ... Examples: | value | result |
Example 1 — happy + edge + error
Feature: Auto-clip videos into Shorts
Scenario: Long video clips successfully
Given a 12-min video is uploaded When auto-clip runs Then ≥3 clips of 9:16 And each has subtitles And each ≤60s
Scenario: Too short (edge)
Given a 40s video When clip is attempted Then "needs 1+ min" is shown And the button is disabled
Scenario: Processing failure (error)
Given a video sent to clip When the service is down Then a retry error is shown And the source is not deleted
Example 2 — auth
Feature: Cloud login
Scenario: Successful login
Given a registered user with valid credentials When they submit email+password Then they reach their account And the personal core syncs
Scenario: Wrong password
Given a registered user When they submit a valid email and wrong password Then "invalid email or password" is shown But the exact reason is not revealed (security)
Quality checklist
- One scenario = one idea.
- Given/When/Then not mixed.
- Usually one When per scenario.
- Then is observable & unambiguous.
- Happy + edges + errors covered.
- Worded from behavior, not implementation.
Common mistakes
Action in Given; multiple actions in one When; impression results; coupling to implementation; happy path only.