mcpField
B
bdd-gherkin-specification

bdd-gherkin-specification

github.com/jzallen测试与质量1133 次安装50 周前更新
代码仓库

关于 bdd-gherkin-specification

面向产品、开发和测试团队的 BDD 与 Gherkin 规范编写技能，帮助将业务需求整理为可读、可执行的场景，并提供语法、示例和审查参考。

主要功能

  1. 01编写 Given-When-Then 场景
  2. 02提供 Gherkin 语法参考
  3. 03涵盖场景编写最佳实践
  4. 04介绍反模式与套件组织

适用场景

  1. 01为用户故事编写验收标准
  2. 02用业务示例记录需求
  3. 03审查和改进 Gherkin 场景

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/jzallen/fred_simulations --skill bdd-gherkin-specification

安装后在 Claude Code 中输入/bdd-gherkin-specification确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

reference/
anti-patterns.md
best-practices.md
examples.md
gherkin-syntax.md
organization.md
quick-reference.md

详细介绍

BDD 与 Gherkin 规范

你是行为驱动开发（BDD）和 Gherkin 规范编写方面的专家。这项技能可帮助你创建清晰、可执行的规范，连接业务需求与技术实现。

什么是 BDD？

BDD 是一种收集需求的方法，通过真实示例来描述功能的行为。它使用共同的语言和具体场景，弥合业务相关方、开发人员和测试人员之间的差距。

什么是 Gherkin？

Gherkin 是一种纯文本语言，使用 Feature、Scenario、Given、When、Then 等关键字编写 BDD 场景。它易于阅读，以业务为中心，并可作为自动化测试执行。

何时使用这项技能

在以下情况下使用：

  • 为用户故事定义验收标准
  • 创建持续更新的文档
  • 弥合技术和非技术相关方之间的沟通鸿沟
  • 规范复杂的业务规则
  • 在跨职能团队中工作

在以下情况下不要使用：

  • 需求纯属技术性（架构、重构）
  • 团队规模较小，成员集中办公且始终保持沟通
  • 功能过于简单，无需正式规范

快速入门

Gherkin 基本结构：

Feature: User Login

  Scenario: Successful login with valid credentials
    Given the user is on the login page
    When the user enters valid credentials
    Then the user should be redirected to the dashboard

可用资源

核心文档

  • gherkin-syntax.md - Gherkin 语言完整参考

    • 基本结构和文件命名
    • Given-When-Then 详细说明
    • 所有关键字（Feature、Scenario、Background、Scenario Outline、Rule）
    • AND/BUT 的用法
    • 阅读时机：编写第一个功能文件或需要查阅关键字时

  • best-practices.md - 编写有效场景

    • 声明式与命令式风格
    • 保持场景聚焦且相互独立
    • 语言和视角保持一致
    • 明确结果和业务价值
    • 阅读时机：评审或改进场景质量时

  • examples.md - 真实功能文件示例

    • 不同领域的完整功能文件
    • 产品搜索、购物车、身份验证
    • Background 和 Scenario Outline 的用法
    • 并列对比（好与差）
    • 阅读时机：需要灵感或想了解实际应用模式时
进阶主题

  • anti-patterns.md - 常见错误及避免方法

    • 测试实现而非行为
    • 语言过于技术化
    • 场景之间存在依赖
    • 以 UI 为中心而非以行为为中心
    • 阅读时机：排查问题或进行代码评审时

  • organization.md - 组织大型功能文件套件

    • 目录结构模式
    • 何时拆分功能
    • 使用 Rules 对场景分组
    • 团队协作模式
    • 阅读时机：设置项目结构或扩大 BDD 应用范围时

  • quick-reference.md - 速查表和模板

    • 可复制的功能文件模板
    • 一览关键字
    • 常见模式
    • 快速决策树
    • 阅读时机：需要快速查找或回顾时

核心原则

  1. 采用声明式风格 - 描述应发生什么行为，而非如何实现
  2. 保持聚焦 - 一个场景对应一种行为（最多 5-10 个步骤）
  3. 相互独立 - 场景之间不应相互依赖
  4. 使用业务语言 - 避免技术术语，使用用户的语言
  5. 确保可读 - 团队中的任何人都应能理解场景

典型工作流

  1. 从示例入手 - 阅读 examples.md 了解模式
  2. 学习语法 - 参考 gherkin-syntax.md 了解关键字
  3. 编写场景 - 使用 quick-reference.md 中的模板
  4. 评审质量 - 对照 best-practices.md 检查
  5. 避免错误 - 评审时查看 anti-patterns.md

快速提示

  • 先编写场景，再编写代码（场景是规格说明，不是测试）
  • 每个场景都应能独立理解
  • 使用 Background 设置各场景通用的前置条件
  • 使用 Scenario Outline 测试多个相似案例
  • 使用 Rule 对相关场景进行分组
  • 每个功能文件不超过 20 个场景（超过时请拆分）

文件命名约定

使用小写字母和下划线：user_authentication.feature、shopping_cart_checkout.feature

请记住

BDD 场景是写下来的对话，而不是测试脚本。产品负责人、开发人员和测试人员都应该能轻松读懂。如果理解场景需要技术知识，那它就不够声明式。

如需全面的指导，请根据当前需求查看 reference/ 目录。

评论

支持 Markdown