<< All versions
Skill v1.0.0
currentAutomated scan100/100thebushidocollective/han/bdd-patterns
──Details
PublishedSeptember 28, 2026 at 08:26 AM
Content Hashsha256:a591058f40df916b...
Git SHA
──Files
Files (1 file, 3.4 KB)
SKILL.md3.4 KBactive
SKILL.md · 120 lines · 3.4 KB
version: "1.0.0" name: bdd-patterns user-invocable: false description: Use when applying Behavior-Driven Development patterns including Given-When-Then structure, feature files, and acceptance criteria. Use when writing BDD-style tests and specifications. allowed-tools:
- Bash
- Read
BDD Patterns
Master Behavior-Driven Development patterns to write clear, business-readable specifications that drive implementation.
Given-When-Then Structure
The fundamental BDD pattern uses three parts:
- Given: The initial context or preconditions
- When: The action or event being tested
- Then: The expected outcome or result
gherkin
Feature: User AuthenticationScenario: Successful login with valid credentialsGiven a registered user with email "user@example.com"And the user has password "secure123"When the user submits the login form with correct credentialsThen the user should be redirected to the dashboardAnd a session should be created
Feature File Organization
gherkin
Feature: Shopping CartAs a customerI want to manage items in my cartSo that I can purchase products I'm interested inBackground:Given I am logged in as a customerAnd the product catalog is availableScenario: Add item to empty cartGiven my cart is emptyWhen I add "Blue T-Shirt" to my cartThen my cart should contain 1 itemAnd the cart total should be $29.99Scenario: Remove item from cartGiven my cart contains "Blue T-Shirt"When I remove "Blue T-Shirt" from my cartThen my cart should be empty
Scenario Outlines for Data-Driven Tests
gherkin
Scenario Outline: Password validationGiven I am on the registration pageWhen I enter password "<password>"Then I should see "<message>"Examples:| password | message || abc | Password too short || abcdefgh | Password needs a number || abcdefgh1 | Password accepted || abcdefgh1! | Password accepted |
Step Definition Patterns
ruby
# Ruby/Cucumber exampleGiven('a registered user with email {string}') do |email|@user = User.create!(email: email, password: 'password123')endWhen('the user submits the login form with correct credentials') dovisit login_pathfill_in 'Email', with: @user.emailfill_in 'Password', with: 'password123'click_button 'Log In'endThen('the user should be redirected to the dashboard') doexpect(page).to have_current_path(dashboard_path)end
When to Use This Skill
Use bdd-patterns when you need to:
- Write acceptance tests that stakeholders can understand
- Define behavior before implementation
- Create living documentation from tests
- Bridge communication between developers and business
- Ensure features meet business requirements
Best Practices
- Write scenarios from the user's perspective
- Keep scenarios focused on single behaviors
- Use declarative language, not implementation details
- Reuse step definitions across scenarios
- Use Background for common setup steps
- Keep feature files organized by domain area
Common Pitfalls
- Writing scenarios that are too technical
- Coupling steps to specific UI implementations
- Creating overly complex scenario outlines
- Not maintaining feature files as code changes
- Mixing multiple behaviors in one scenario