我的智能体技能：测试驱动开发

# 我的测试驱动开发智能体技能 - SaturnCI - Ruby on Rails 持续集成 来源：https://www.saturnci.com/my-agent-skill-for-test-driven-development.html 至少就目前而言，AI 智能体在编写测试方面表现往往很糟糕。它们写出的测试常常含糊不清、晦涩难懂、过于复杂、拼凑马虎、混乱无序、同义反复、流于形式、敷衍了事，甚至毫无意义。 遗憾的是，我不指望未经指导的智能体在短期内能大幅改进测试编写，因为智能体是从人类编写的示例中学习的，而目前存在的这些人类示例，恕我直言，往往同样糟糕。不仅“业余人士”写的测试常常质量低劣，而且可悲的是，许多“教师”所宣扬的测试实践也相当差劲。现状确实很糟糕。 好消息是，我发现只要稍加引导，智能体就能遵循合理的 TDD 流程，并写出清晰、有意义的测试。那么，这种引导具体是什么呢？简短的答案——可以视作接近真相的近似——就是 Kent Beck 的 Canon TDD（https://tidyfirst.substack.com/p/canon-tdd）。如果你给智能体一个技能，里面只写“遵循 Kent Beck 的 Canon TDD”，我想你就能完成 60% 的工作。更长的答案则是我融入自己个人 TDD 技能中的内容。 ## 我的 TDD 技能 由于这是一个不断更新的文档，我不想把我的 TDD 技能写死在这篇博文中。相反，你可以在 GitHub 上看到我的 TDD 技能（https://github.com/jasonswett/llm-skills/blob/main/tdd/SKILL.md）。话虽如此，我仍然可以在这里分享这个技能的核心，因为我相信这部分不会改变。 首先，我向智能体介绍我称之为“指定-编码-实现”的循环，这是我对红-绿-重构的个人替代方案。指定-编码-实现（SEF）的流程如下： 1. **指定**：为你要构建的内容提出规格说明 2. **编码**：将这些规格说明编码为自动化测试（可执行规格） 3. **实现**：编写代码来实现这些规格说明 SEF 是我对 TDD 精髓的高层理解。在稍低的层面上，则是 Kent Beck 的 Canon TDD，我用我自己的话描述如下： 1. 在当前 TDD 会话范围内，列出要实现的规格说明 2. 将列表中的每一项编码为一个自动化测试 3. 仅修改刚好能让当前测试失败消失的代码。避免“投机编码”——如果我们编写的代码比让当前测试失败消失所需的更多，就有可能产生从未被任何测试覆盖的代码 4. 可以选择重构，但前提是在提交行为变更之后。永远不要将行为变更与重构混在一起 5. 直到列表为空，返回第 2 步 我的 TDD 技能包含更多细节，但这是流程的核心。不过，这个流程对测试本身的设计影响不大，所以我为此准备了另一个技能：测试设计审查（https://github.com/jasonswett/llm-skills/blob/main/test-design-review/SKILL.md）。测试设计审查会生成一个独立的智能体（以避免偏见），查找违反设计原则的情况（例如测试关注手段而非目的），并提出修复建议。有时“修复”值得商榷，但通常都切中要害。当我对智能体编写某个测试的方式不满意时，我会运行测试设计审查，试图让智能体自己发现错误。 ## 通用设计审查 许多测试设计违规实际上只是违反了通用软件设计原则，例如“名实相符”原则。除了通过测试设计审查技能来审视我的测试之外，我还喜欢通过我的软件设计审查技能（https://github.com/jasonswett/llm-skills/blob/main/software-design-review/SKILL.md）来审查它们。 我的智能体有时会让我感到惊讶。在我的 TDD 技能中，我加入了一条指令，虽然并不指望它一定能被遵循：如果发现编写我们想要写的测试很困难，这可能意味着我们需要“在做饭前先打扫厨房”。不知为何，Claude 真的把这句话记在心里了，它经常停下来询问我们是否应该先打扫厨房，而很多时候，我们的确应该这么做。 我还没有让我的智能体 100% 写出可接受的测试，远远没有，但我的 TDD 技能已经足够好用，以至于它成了我进行任何变更的默认方式。将这些 TDD 和测试设计原则付诸实践能产生如此好的结果，我并不感到意外。在我看来，AI 最大的生产力提升来自于将 AI 与那些永恒不变的原则相结合——这些原则几十年前就被发现，今天依然成立，而且无论出现什么新技术，它们都永远不会失去价值。