behavior-driven-development

行为驱动开发（BDD）技能

本技能提供了一份全面指南，介绍如何将行为驱动开发原则应用于编码任务。BDD 不只是关于工具；它还是一种帮助团队建立共识并实现高质量成果的方法论。

如何使用此技能

当用户提出功能开发、错误修复或重构需求时，请遵循以下思路：

1. 先理解行为： 在明确系统应该 做什么 之前，不要开始编码。
2. 定义场景： 编写或请用户提供预期行为的具体示例（Gherkin）。
3. 以测试驱动实现： 使用 Red-Green-Refactor 循环。

核心概念

1. BDD 循环

流程从需求到代码依次展开：

• 探索： 通过示例澄清需求（“三位好友”）。
• 描述： 使用具体场景（Given/When/Then）编写这些示例。
• 自动化： 使用 TDD 实现。

详细指南请参阅 ./references/bdd-best-practices.md。

2. 编写场景（Gherkin）

场景是你的“可执行规范”。

• 保持声明式（关注业务）。
• 避免使用技术术语和 UI 细节。
• 每个场景只描述一种行为。
• 在 superpowers 工作流中，将 bdd-specs.md 作为规划阶段的场景清单。在头脑风暴和编写计划期间，将经过审阅的 Given/When/Then 场景保存在 docs/plans/.../bdd-specs.md 中，以便设计评审、任务拆分和迭代契约都以同一来源为准。
• 将可执行场景存储在 .feature 文件中，而不是代码注释中——实现开始后，将需要自动化的场景转换为 .feature 文件或框架原生的可执行测试格式。bdd-specs.md 用于设计和规划；.feature 文件用于自动化和持续更新的文档。

语法和存储结构请参阅 ./references/gherkin-guide.md。

3. Red-Green-Refactor（TDD）

实现的核心：

1. RED： 针对场景（或其一个单元）编写一个会失败的测试。
2. GREEN： 编写能够通过测试的最少代码。
3. REFACTOR： 在确保测试仍然通过的同时清理代码。

重要：铁律

“没有先编写会失败的测试，就不编写生产代码。”

在编写任何实现之前，RED 步骤必须验证测试因正确的原因而失败（运行测试并查看失败输出）。跳过或为此寻找理由会导致：

1. 测试莫名其妙地通过——你无法确定它们是否真的能失败。
2. 受实现偏见影响的测试——它们反映的是已编写的代码，而不是约定的行为。
3. 从第一天起就留下遗留代码——没有行为安全网来捕获未来的回归。

如果生产代码已经存在

删除它，并从一个会失败的测试重新推导实现——不要把它“留作参考”，不要将它“改编”为先写测试的版本，也不要在编写测试时阅读它。以上任何做法都会通过后门再次引入上述测试偏向实现的问题：如果编写测试时看着它要约束的代码，那么无论测试是否检查了正确的行为，它都可能一次通过。删除就是删除。

常见的合理化说辞（全部驳回）

合理化说辞	为什么站不住脚
“我之后再写测试——覆盖率一样”	针对可运行代码编写的测试，第一次运行总会通过。这只能证明测试没有崩溃，不能证明它验证了正确的行为。只有先失败、且因所述原因失败的测试，才能证明它有能力捕获回归问题。
“我已经手动验证过它能正常工作”	手动验证无法重复执行，也无法防止回归。它回答的是“这次是否正常工作”，而不是“以后是否会一直正常工作”。
“这太简单了，不需要测试”	简单代码和复杂代码一样容易改变行为。“铁律”没有复杂度门槛——它只有下面列出的三个例外，没有其他例外。
“我会灵活处理 TDD，而不是教条地遵守”	这只是另一种合理化说辞，并非替代方案。这些表格中的每一条，都是有人在“灵活处理”时跳过 Red 步骤。
“我已经花了一个小时，删掉它太浪费了”	这是沉没成本。无论删掉还是保留代码，这一个小时都已经花掉了；保留未经测试的代码无法挽回这一个小时，只会额外带来未经验证的回归风险。

唯一合理的例外列于 ./references/bdd-best-practices.md（一次性原型、生成的代码、配置文件）——即使是这些情况，也应向用户说明，而不是默默自行假定。

事后编写的测试回答的是另一个问题

先写测试，会将“系统约定要做什么”编码进去。事后写测试，则会将“我已经写好的代码碰巧做了什么”编码进去——即使代码行为有误，测试也会通过，因为测试是为了匹配该行为而编写的，并非依据独立规范。如果你发现自己正在针对已能看到的代码编写测试，请停下来，删除代码，然后针对行为编写测试。

参考资料

• ./references/bdd-best-practices.md - BDD 方法论、探索、编写和自动化
• ./references/gherkin-guide.md - Gherkin 场景语法、存储结构和示例
• ./references/testing-anti-patterns.md - Mock 的陷阱，以及其他可能导致测试通过却未验证真实行为的做法