behave-testing
Configures Behave for Python BDD scenarios - `pip install behave`, authors `.feature` files in Gherkin, writes step implementations in `features/steps/*.py`, configures via `environment.py` for setup/teardown hooks, organizes via tags, runs via `behave`. Use for Python codebases that want Cucumber-family BDD without Cucumber-Ruby / Cucumber-JS.
Install with skills.sh (any agent)
npx skills add testland/qa --skill behave-testingbehave-testing
Overview
Per behave-docs (opens in new window):
"behave is behaviour-driven development, Python style." It employs "tests written in a natural language style, backed up by Python code."
Per behave-docs (opens in new window): "Behavior-driven development encourages collaboration between developers, QA and non-technical or business participants in a software project."
Per cucumber-install (opens in new window), Behave is in the semi-official Cucumber tier (uses Cucumber components but maintained outside the main org).
When to use
Step 1 - Install
pip install behaveStep 2 - Project layout
Behave's conventional layout:
project/
├── features/
│ ├── cart.feature # Gherkin features
│ ├── steps/
│ │ ├── cart_steps.py # step implementations
│ │ └── shared_steps.py
│ └── environment.py # setup/teardown hooks
└── ...Step 3 - Author a Feature
# features/cart.feature
Feature: Apply promo code at checkout
Background:
Given a logged-in user
And the cart contains 1 of "BOOK-001" at $24.99
Scenario: Apply valid promo
When I enter "WELCOME10" in the promo input
And I click "Apply"
Then the subtotal updates to $22.49
Scenario Outline: Promo validation
When I enter "<code>" in the promo input
And I click "Apply"
Then an error appears: "<error>"
Examples:
| code | error |
| EXPIRED50 | This code has expired |
| NOTREAL | Code not found |Step 4 - Write step implementations
# features/steps/cart_steps.py
from behave import given, when, then
from app.cart import Cart
from app.checkout import CheckoutPage
from tests.fixtures import login_user
@given('a logged-in user')
def step_logged_in_user(context):
context.user = login_user()
context.page = CheckoutPage(context.user)
@given('the cart contains {qty:d} of "{sku}" at ${price:f}')
def step_cart_contains(context, qty, sku, price):
context.cart = Cart()
context.cart.add_item(sku, qty, price)
context.page.set_cart(context.cart)
@when('I enter "{code}" in the promo input')
def step_enter_promo(context, code):
context.page.enter_promo(code)
@when('I click "{label}"')
def step_click(context, label):
context.page.click(label)
@then('the subtotal updates to ${expected:f}')
def step_subtotal(context, expected):
assert abs(context.page.get_subtotal() - expected) < 0.01, \
f"Expected {expected}, got {context.page.get_subtotal()}"
@then('an error appears: "{message}"')
def step_error(context, message):
assert message in context.page.get_error_message()The context object carries state across steps within a scenario.
Step 5 - Hooks via environment.py
Per behave-docs (opens in new window), environment.py provides "Environmental Controls":
# features/environment.py
def before_all(context):
"""Once before any scenario runs."""
context.config.setup_logging()
context.db = setup_test_database()
def after_all(context):
"""Once after all scenarios finish."""
context.db.close()
def before_scenario(context, scenario):
"""Before each scenario."""
context.db.start_transaction()
def after_scenario(context, scenario):
"""After each scenario (use scenario.status to check pass/fail)."""
context.db.rollback()
def before_tag(context, tag):
"""Before scenarios with a specific tag."""
if tag == 'requires_browser':
context.browser = launch_browser()
def after_tag(context, tag):
if tag == 'requires_browser':
context.browser.quit()The hook hierarchy: before_all > before_feature > before_scenario > before_step (and the matching after_*).
Step 6 - Tags + filtering
Per behave-docs (opens in new window), "Controlling Things With Tags" is the filter mechanism:
@critical @regression
Scenario: Apply valid promo
...
@wip
Scenario: New checkout flow (work in progress)
...# Run only critical
behave --tags=critical
# Skip wip
behave --tags=~wip
# Combine
behave --tags=critical --tags=~slowStep 7 - Reporting
# Plain text + JUnit XML for CI
behave --junit --junit-directory reports/junit/
# Per-feature output, no colors
behave --format=plain --no-color > test-results.txtThe JUnit XML feeds junit-xml-analysis (in the qa-test-reporting plugin).
Step 8 - Run
behave # all features
behave features/cart.feature # one feature
behave --tags=@critical # by tag
behave -i cart # match file patternStep 9 - pytest-bdd alternative
Per behave-docs (opens in new window), Behave is the canonical Python BDD; the ecosystem also includes pytest-bdd which integrates Gherkin into pytest. Choose:
| Behave | pytest-bdd |
|---|---|
| Standalone runner | pytest plugin |
| Closer to Cucumber semantics | Reuses pytest fixtures |
| Better for pure-BDD teams | Better when mixing BDD + xUnit-style tests |
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
Mixing fixtures across context and module-level state | Hidden coupling; test order matters. | Use context only; reset per scenario via before_scenario (Step 5). |
| Step regex too greedy | One step matches multiple Gherkin lines. | Use {var} placeholders + type hints ({qty:d} per Step 4). |
before_all setup that fails | All scenarios fail; debugging hard. | Quick smoke check in before_all; fail fast with clear message. |
@wip scenarios shipping in CI | Test runner counts them as passes. | behave --tags=~wip in CI (Step 6). |
| One step file with 200 steps | Hard to navigate; merge conflicts. | Split per-feature: cart_steps.py, checkout_steps.py, etc. |
Limitations
References
Related skills
bdd-step-library-curator
Keeps a BDD step-definition library DRY across a Cucumber / Behave / Reqnroll project - inventories every step definition, detects duplicates (different patterns matching the same intent), recommends canonical consolidations, reorganizes steps by domain, publishes a step-library README the team greps for "is there already a step for X?" before authoring new ones, and builds a scenario coverage map that fingerprints new Gherkin scenarios against the live suite to classify each as duplicate, partial overlap, or genuine gap before any test is authored. Use when a BDD project's step count grows past ~50, on a quarterly step-library review, when a new engineer is about to write a duplicate step, or when fresh .feature files need a covered-already check.
cucumber-testing
Configures Cucumber for BDD scenarios - Cucumber-JVM (Java/Kotlin via JUnit 5), Cucumber-JS (Node), Cucumber-Ruby. Authors `.feature` files in Gherkin, writes step definitions in the host language, runs via the framework's runner, integrates with JUnit XML reporting. Use when the user mentions Cucumber, Gherkin, `.feature` files, or behavior-driven (BDD) tests in Java, Kotlin, JavaScript, or Ruby, as the canonical wrapper for any of the three official implementations.
gherkin-from-stories
Converts requirements in any input shape into Gherkin scenarios - a user story ("As a … I want … so that …"), a signed-off acceptance-criteria list (ATDD: @AC-N-tagged scenarios, NotImplementedError step stubs, AC-to-test traceability table), existing manual test steps (declarative rewrite that strips UI mechanics), or a raw spec / PRD section (acceptance-criteria extraction with Gherkin or plain-list output). Maps criteria to Scenario blocks, detects Scenario Outline opportunities, factors shared Background, reuses the curated step library, and flags implicit preconditions instead of fabricating them. Emits Gherkin (plus stubs in ATDD mode): runner detection and full step wiring belong to bdd-scenario-author. Use whenever requirements text of any shape needs to become a .feature file.
living-documentation-publisher
Converts passing Cucumber JSON output into stakeholder-facing living documentation: generates HTML reports via multiple-cucumber-html-reporter (Node) or Serenity BDD aggregate (JVM), applies Gherkin tags to drive report sections, and publishes to GitHub/GitLab Pages in CI. Use when BDD scenarios are in use and the team needs an always-current, non-test-engineer-readable document showing which acceptance criteria pass.
reqnroll-testing
Configures Reqnroll (the canonical .NET BDD framework) - install via `dotnet add package Reqnroll`, author `.feature` files in Gherkin, write step bindings as `[Given/When/Then]`-decorated methods in any C# class, runs via `dotnet test`. Reqnroll is the SpecFlow successor (SpecFlow reached end-of-life 2024-12-31); covers the SpecFlow-to-Reqnroll migration path, and references/specflow-legacy.md maintains not-yet-migrated SpecFlow projects. Use for .NET projects starting BDD, migrating from SpecFlow, or maintaining legacy SpecFlow suites.