AgentSkillsCN

bdd-acceptance-tests

BDD 接受测试标准。在编写 Cucumber/Gherkin 场景、实施端到端测试，或配置发布门禁时，可参考此标准。内容涵盖 Given/When/Then 格式、关键路径场景，以及与 CI 系统的无缝集成。

SKILL.md
--- frontmatter
name: bdd-acceptance-tests
description: |
  BDD acceptance testing standards. Use when writing Cucumber/Gherkin scenarios,
  implementing end-to-end tests, or configuring release gates. Covers
  Given/When/Then format, critical path scenarios, and CI integration.
disposition: always
compliance:
  - soc2: CC5.2
  - iso27001: A.14.2.8
version: 1.0.0

Enforce BDD Acceptance Tests for Critical Business Scenarios

Description

This rule mandates that critical business flows are validated using end-to-end acceptance tests written in Behavior-Driven Development (BDD) format. These tests must run as part of every release candidate CI pipeline, and all critical path scenarios must pass before deployment.

Purpose

To validate that high-value business behaviors function as expected in an integrated system. BDD-style tests ensure shared understanding between stakeholders and technical teams while guarding against regressions in core functionality.

Scope

  • •All product features considered part of the “critical path” (e.g., sign-up, donation, reporting)
  • •End-to-end test scenarios using tools like Cucumber, Cypress, Playwright, or similar
  • •Executed in CI for every release branch or tag
  • •Product owners, QA engineers, and release managers

SDLC Integration

  • •Planning: Acceptance criteria written in Given/When/Then format
  • •Analysis: Scenarios linked to work items and epics
  • •Design: System states and user flows captured via feature files
  • •Development: BDD scenarios automated as tests
  • •Testing: Tests executed on pre-release CI stage
  • •Deployment: Release blocked if scenario fails
  • •Maintenance: Test coverage and relevance reviewed per iteration

Standards

Acceptance Test Requirements

  • •BDD-style acceptance tests MUST be written for all critical business behaviors
  • •Tests MUST execute in CI before any release approval
  • •All critical path scenarios MUST pass with 100% reliability
  • •Acceptance tests SHOULD complete within SLA (< 5s per user-critical step)
  • •Flaky or non-deterministic tests MUST be resolved before release

Actionable Metrics

MetricTarget ValueMeasurement MethodEnforcement Level
Critical path test pass rate100 %CI pipeline logsMUST
Scenario execution per release100 %Tag-triggered test reportMUST
Step execution time (SLA check)< 5 secondsTest framework performance logSHOULD

Implementation

Configuration Requirements

  • •Use .feature files or annotated E2E tests with clear Given/When/Then structure
  • •Integrate into CI stage gated by release candidate tags
  • •Fail CI if any critical path scenario fails

Example: Correct Implementation

gherkin
Feature: Donation visibility

Scenario: Donation by new user appears in dashboard
  Given a new user signs up
  When they donate $10 to a project
  Then the donation appears in the dashboard within 5 seconds