Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →nwave-ai/nw-bdd-methodology
BDD patterns for acceptance test design - Given-When-Then structure, scenario writing rules, pytest-bdd implementation, anti-patterns, and living documentation
Passed 19 of 22 test cases with the skill, and 18 of 22 without it.
2 fixed17 passed either way2 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
Here is a raw specification for an automated transfer feature between bank accounts. Please write the BDD acceptance test scenarios using declarative Given-When-Then formatting, and then provide the matching pytest-bdd Python step definitions organized logically by domain concepts with proper fixture usage.
| Checked | Without skill | With skill |
|---|---|---|
| Scenarios stay within 3 to 5 steps each | Missed | Passed |
| Step definitions are grouped into separate module files by domain concept rather than unified in one test file | Missed | Passed |
The instructions your model reads when the skill loads.
Test units of behavior, not units of code. Acceptance tests validate business outcomes through public interfaces, decoupled from implementation.
The acceptance-designer creates the outer loop of Outside-In TDD. Development starts from user perspective, drives inward.
Outer loop (acceptance/BDD): Hours to days | User perspective, business language | Defines "done" | Scenarios describe user goals and observable outcomes, not internals | Failing outer-loop test is the starting signal for implementation
Inner loop (unit/TDD): Minutes | Developer perspective, technical terms | Software-crafter owns this loop
Workflow:
Outer loop defines WHAT users need (outside). Inner loop drives HOW to build it (inside).
Scenario: [Business-focused title describing one behavior]
Given [preconditions - system state in business terms]
When [single user action or business event]
Then [observable business outcome]
Rule 1: One scenario, one behavior -- Split multi-behavior scenarios.
Rule 2: Declarative, not imperative -- Business outcomes, not UI interactions. "When I log in with valid credentials" not "When I click Login button and enter email."
Rule 3: Concrete examples, not abstractions -- "Given my account balance is $100.00" not "Given the user has sufficient funds."
test cases passed, vs 18 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.