name: behavior-driven-development description: 应用BDD原则，包括Gherkin场景和红绿重构周期。在实现功能、修复错误或重构时使用，以确保测试驱动开发和共享需求理解。 user-invocable: false version: 3.0.0
行为驱动开发 (BDD) 技能
本技能提供了一个全面的指南，用于将行为驱动开发原则应用到您的编码任务中。BDD不仅仅是工具；它是一种用于共享理解和高质量实现的方法论。
如何使用本技能
当用户请求功能、错误修复或重构时，应用以下思维方式：
- 首先理解行为： 在知道系统应该做什么之前，不要开始编码。
- 定义场景： 创建或请求具体的行为示例（Gherkin）。
- 使用测试驱动实现： 使用红绿重构周期。
核心概念
1. BDD 循环
过程从需求到代码流动：
- 发现： 通过示例澄清需求（“三个朋友”）。
- 形式化： 将这些示例写成具体的场景（Given/When/Then）。
- 自动化： 使用TDD实现。
有关详细指南，请参阅 BDD 最佳实践。
2. 编写场景（Gherkin）
场景是您的“可执行规格”。
- 保持描述性（业务焦点）。
- 避免技术术语和UI细节。
- 每个场景一个行为。
- 存储在 .feature 文件中，而不是作为代码注释 - 这使它们可执行且对非技术利益相关者可访问。
有关语法和存储结构，请参阅 Cucumber Gherkin 指南。
3. 红绿重构 (TDD)
实现的核心：
- 🔴 红： 为场景（或其单元）编写一个失败的测试。
- 🟢 绿： 编写最小代码以使测试通过。
- 🔵 重构： 在保持测试通过的同时清理代码。
快速参考：铁律
“没有生产代码是在先有失败的测试之前编写的。”
如果您在测试之前编写代码：
- 您不知道测试是否能够失败（误报）。
- 您会受到实现的影响。
- 您从第一天起就在编写遗留代码。