Testland
Browse all skills & agents

acceptance-test-from-criteria

ATDD (Acceptance Test-Driven Development) workflow that generates @AC-N-tagged Gherkin scenarios from a signed-off acceptance-criteria list, scaffolds NotImplementedError step stubs, and produces an AC-to-test traceability table, all before implementation begins, in the team's BDD framework (Cucumber / Behave / Reqnroll). Use when devs are gated on green acceptance tests and failures must map back to a specific criterion. For story-narrative-to-Gherkin without prior ACs, use gherkin-from-stories. For BDD scenario authoring without the ATDD test-first gate, use a general BDD scenario-authoring workflow.

Install with skills.sh (any agent)

npx skills add testland/qa --skill acceptance-test-from-criteria
View source

acceptance-test-from-criteria

Overview

Per ISTQB Glossary V4.7.1: ATDD (Acceptance Test-Driven Development) is "a collaboration-based test-first approach that defines acceptance tests in the stakeholders' domain language."

The shift-left flow:

Story → AC → Acceptance test (this skill) → Implementation → Pass

The acceptance test is written first (test-first); the implementation follows; success = test passes.

This is BDD's variant where the AC is the source of truth; the test is the executable formalization.

When to use

  • The team practices ATDD (test-first from acceptance criteria).
  • Each story's acceptance is gated on the corresponding tests passing.
  • The team wants AC-to-test traceability for compliance / audit.

For Gherkin generation from prose stories, see gherkin-from-stories. For upstream AC extraction, see acceptance-criteria-extractor (in the qa-shift-left plugin).

Step 1 - Read the AC list

## Acceptance criteria

- AC-1.1: Valid promo "WELCOME10" reduces subtotal by 10%.
- AC-1.2: Expired promo shows the message "This code has expired."
- AC-1.3: Empty promo input shows "Please enter a code."
- AC-1.4: Already-applied promo shows "Already applied" without re-applying.
- AC-1.5: Promo applies before tax (per current pricing logic).

Each AC has an ID - preserved end-to-end so test failures map back.

Step 2 - One test per AC

# Features/promo-application.feature
Feature: Apply promo code at checkout

  Background:
    Given a logged-in customer
    And the cart contains 1 of "BOOK-001" at $24.99

  @AC-1.1
  Scenario: Valid promo reduces subtotal
    Given promo code "WELCOME10" is active
    When I enter "WELCOME10" in the promo input
    And I click "Apply"
    Then the subtotal updates to $22.49

  @AC-1.2
  Scenario: Expired promo shows error
    Given promo code "EXPIRED50" is inactive
    When I enter "EXPIRED50" in the promo input
    And I click "Apply"
    Then an error appears: "This code has expired"

  @AC-1.3
  Scenario: Empty promo input
    When I enter "" in the promo input
    And I click "Apply"
    Then an error appears: "Please enter a code"

  @AC-1.4
  Scenario: Already-applied promo
    Given promo code "WELCOME10" is active
    And I have already applied "WELCOME10"
    When I enter "WELCOME10" in the promo input
    And I click "Apply"
    Then an error appears: "Already applied"
    And the subtotal remains $22.49

  @AC-1.5
  Scenario: Promo applies before tax
    Given the tax rate for this region is 10%
    And promo code "WELCOME10" is active
    When I enter "WELCOME10" in the promo input
    And I click "Apply"
    Then the subtotal updates to $22.49
    And the tax updates to $2.249 (10% of $22.49)
    And the total is $24.74

The @AC-X.Y tag is the load-bearing traceability: failing tests report which AC failed.

Step 3 - Initial state - all tests fail

Per ATDD, tests are written before implementation. Initial run:

Scenario: Valid promo reduces subtotal
  Given promo code "WELCOME10" is active                    # PASS (admin seeding works)
  When I enter "WELCOME10" in the promo input               # PASS (input field exists)
  And I click "Apply"                                        # PASS (button exists)
  Then the subtotal updates to $22.49                       # FAIL - promo logic not implemented

5 of 5 scenarios FAILED (as expected - implementation pending).

The failing tests are the work backlog.

Step 4 - Implementation drives tests green

Engineer implements the promo logic; tests turn green one by one:

After implementing valid-promo path:
  AC-1.1 ✅
  AC-1.2 ❌ (expired logic still missing)
  AC-1.3 ❌
  AC-1.4 ❌
  AC-1.5 ❌

After implementing all paths:
  AC-1.1 ✅
  AC-1.2 ✅
  AC-1.3 ✅
  AC-1.4 ✅
  AC-1.5 ✅

Story is "done" only when all AC tests pass - per the team's DoD (definition-of-done in the qa-process plugin).

Step 5 - Scaffold new step definitions

The skill detects undefined steps and emits stub definitions:

# features/steps/promo_steps.py

@given('promo code "{code}" is active')
def step_promo_active(context, code):
    raise NotImplementedError(f"Implement: seed promo {code} as active")

@given('promo code "{code}" is inactive')
def step_promo_inactive(context, code):
    raise NotImplementedError(f"Implement: seed promo {code} as expired")

@when('I enter "{code}" in the promo input')
def step_enter_promo(context, code):
    raise NotImplementedError(f"Implement: type {code} in promo input")

@when('I click "{label}"')
def step_click(context, label):
    raise NotImplementedError(f"Implement: click {label}")

@then('an error appears: "{message}"')
def step_error_appears(context, message):
    raise NotImplementedError(f"Implement: assert error message {message}")

@then('the subtotal updates to ${expected:f}')
def step_subtotal(context, expected):
    raise NotImplementedError(f"Implement: assert subtotal == {expected}")

The NotImplementedError body makes the test failure helpful - the engineer knows exactly what to implement.

The implementations land in PRs alongside the production code.

Step 6 - Traceability artifact

## AC-to-test mapping - `<story>` (auto-generated)

| AC ID    | Test                                               | Status   | Last run |
|----------|----------------------------------------------------|----------|----------|
| AC-1.1    | `promo-application.feature:8` (Valid promo)         | ✅ pass  | 2026-05-05 |
| AC-1.2    | `promo-application.feature:14` (Expired)            | ✅ pass  | 2026-05-05 |
| AC-1.3    | `promo-application.feature:20` (Empty)              | ✅ pass  | 2026-05-05 |
| AC-1.4    | `promo-application.feature:25` (Already applied)    | ✅ pass  | 2026-05-05 |
| AC-1.5    | `promo-application.feature:32` (Tax interaction)    | ✅ pass  | 2026-05-05 |

**Coverage:** 5/5 AC covered by tests. Story is testable per ATDD.

This artifact answers: "Did we test what the customer asked for?" A 1:1 mapping of AC → test → status answers it definitively.

Step 7 - Run via the team's framework

Default: match the team's existing BDD runner - ATDD lives or dies by adoption, and forcing a runner switch alongside test-first authoring stalls both. Use the team's incumbent runner (Cucumber-JVM, Behave, or Reqnroll). Pick a new runner only when no incumbent exists; in that case default to the runner matching the production stack's primary language (JVM → Cucumber-JVM, Python → Behave, .NET → Reqnroll).

# Cucumber-JVM
mvn test -Dcucumber.filter.tags='@AC-1.1 or @AC-1.2 or @AC-1.3 or @AC-1.4 or @AC-1.5'

# Behave
behave --tags=@AC-1.1 --tags=@AC-1.2 --tags=@AC-1.3 --tags=@AC-1.4 --tags=@AC-1.5

# Reqnroll
dotnet test --filter "Category=AC-1.1|Category=AC-1.2|..."

Anti-patterns

Anti-patternWhy it failsFix
Tests written after implementationDefeats ATDD; tests verify what was built, not what was asked.Test-first; tests precede implementation.
Tests without @AC-X.Y tagNo traceability; story acceptance unverifiable.Tag every Scenario (Step 2).
One mega-scenario covering all ACsFailure mid-scenario doesn't pinpoint which AC failed.One Scenario per AC (Step 2).
Auto-generated step bodies that pass silentlyTests appear green; production code never runs.NotImplementedError (Step 5).
Skipping the AC-to-test artifactCompliance / audit gap.Generate per Step 6 each release.
AC tests in the same suite as unit testsMixed feedback; harder to interpret.Separate features/acceptance/ suite.

Limitations

  • Requires the team to write ACs first. Doesn't apply to teams without explicit AC artifacts.
  • AC quality drives test quality. Vague AC → vague test (or many implicit-precondition flags per gherkin-from-stories Step 5).
  • Doesn't replace lower-layer tests. ATDD covers the AC layer; unit / integration coverage still needed for non-AC logic.

References

  • acceptance-criteria-extractor (in the qa-shift-left plugin) - upstream: emits the AC this skill consumes.
  • gherkin-from-stories - sibling: story-first variant.
  • bdd-step-library-curator - step library this skill draws from + adds to.
  • cucumber-testing, behave-testing, reqnroll-testing - runners.
  • definition-of-done (in the qa-process plugin) - DoD that requires AC tests to pass.
  • ISTQB Glossary V4.7.1 - https://glossary.istqb.org/en_US/term/acceptance-test-driven-development defines ATDD as "a collaboration-based test-first approach."

Related skills

bdd-overview

Teaches behaviour-driven development end to end for a newcomer: what BDD is and how discovery, formulation and automation fit together; a decision table that picks the runner from the project's language and build files (Cucumber-JVM, Cucumber-JS, Cucumber-Ruby, Behave for Python, Reqnroll for .NET, and why SpecFlow is end-of-life); install and first-run commands for each; the declarative-versus-imperative Gherkin discipline with a worked bad-versus-good pair; Background, Scenario Outline and domain-organised step libraries; the traps that make BDD collapse into an expensive UI-automation wrapper; and an honest account of when BDD is not worth adopting. Use when a team is adopting BDD, choosing a Gherkin runner, or a *.feature file needs writing and nobody has settled the conventions.

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, and publishes a step-library README the team greps for "is there already a step for X?" before authoring new ones. Use when a BDD project's step count grows past ~50, on a quarterly step-library review, or when a new engineer cannot find an existing step and is about to write a duplicate.

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.

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

Build-an-X workflow that converts user stories into Gherkin scenarios - extracts the actor / capability / value triple from "As a … I want … so that …", maps acceptance criteria to Scenario blocks, identifies parameterizable axes for Scenario Outlines, and emits a Feature file ready for `bdd-step-library-curator`-curated step definitions. Starts from the story itself rather than from an already-extracted acceptance-criteria list; this skill operates at the user-story layer and produces Gherkin directly. Emits Gherkin only: no step definition stubs and no runner detection. For a full runnable artifact (Feature file plus scaffolded step definitions), follow this skill with step-definition scaffolding for the detected runner. Use when a PM hands over a user story or a backlog of stories and the team's first test artifact is the `.feature` file rather than a separate AC doc.

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.

manual-step-to-gherkin

Translates an existing manual test step (table row, prose bullet, TestRail/Qase exported step) into a declarative Gherkin Given/When/Then step phrased in business language - strips UI mechanics ("clicks the button", "types in the field"), elevates the user intent ("signs in", "adds the product"), and aligns vocabulary with the project's existing step library. The input is an already-written manual step - not a user story and not an acceptance-criteria list. Use when a team is migrating manual test scripts to BDD, or when a manual tester is handing a script off to an automation engineer.

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 (originated as a community port off the SpecFlow codebase); new .NET BDD work targets Reqnroll. Use for .NET projects starting BDD or migrating from SpecFlow.

specflow-testing

Maintains SpecFlow tests on existing .NET projects - authors Gherkin `.feature` files, writes C# `[Binding]` step definitions, runs them via xUnit/NUnit/MsTest, and migrates a project to Reqnroll. SpecFlow is the legacy .NET BDD framework and Reqnroll is its maintained fork. Use only for existing SpecFlow projects, especially mid-migration; new .NET BDD projects use `reqnroll-testing` instead.