AI智能体编写测试欠佳？掌握TDD技能或能提升60%成功率！

【SaturnCI相关链接】

[SaturnCI] [文档] [博客] [SDK] [关于我们] [登录] [注册]

【AI智能体编写测试现状】

至少就目前而言，AI智能体在编写测试方面表现欠佳。它们编写的测试往往模糊、晦涩、过于复杂、粗糙、杂乱无章、循环论证、流于形式，甚至毫无意义。短期内，未经指导的智能体在编写测试方面不会有太大改善，因为智能体通过人类编写的示例学习，而现有的人类编写的示例往往同样糟糕，不仅“业余者”编写的测试质量不高，“教师”所倡导的测试实践也相当糟糕。

【给予指导后智能体的表现】

好消息是，给予一些指导，智能体就能够遵循合理的TDD流程，并编写清晰、有意义的测试。具体需要怎样的指导呢？近似正确的答案是Kent Beck的 [规范TDD]。让智能体掌握“遵循Kent Beck的规范TDD”，约能成功60%。更详细的内容包含在个人的TDD技能中。

【个人的TDD技能】

由于这是一份动态文档，不想将TDD技能固定在博客文章中，可在GitHub上查看。这里分享该技能的核心内容，首先让智能体了解“指定 - 编码 - 实现”循环，这是个人对“红 - 绿 - 重构”的替代方案。“指定 - 编码 - 实现”（SEF）流程如下：1. 指定：明确想要构建的内容的规格。2. 编码：将这些规格编码为自动化测试（可执行的规格说明）。3. 实现：编写代码以实现这些规格。SEF是TDD的高层概念，稍低一层的是Kent Beck的规范TDD，描述如下：1. 列出当前TDD会话范围内的规格列表。2. 将列表中的每个项目编码为自动化测试。3. 对代码进行最小程度的修改，以使当前的测试失败消失，避免“投机性编码”。4. 可选择进行重构，但要在提交行为更改之后进行，永远不要将行为更改和重构混为一谈。5. 重复步骤2，直到列表为空。TDD技能包含更多细节，但这就是该流程的核心。不过，这个流程对测试本身的设计影响不大，所以还有另一个技能，即测试设计审查。测试设计审查会生成一个单独的智能体，查找是否违反设计原则，并提出修复建议。有时这些“修复建议”可能不太可靠，但通常是正确的。当对智能体编写的某个测试不满意时，会运行测试设计审查，让智能体自己发现错误。

【通用设计审查】

许多测试设计方面的问题其实就是违反了通用的软件设计原则，比如“名符其实”原则。除了使用测试设计审查技能审查测试之外，还喜欢使用软件设计审查技能。

【智能体带来的惊喜】

智能体有时会带来惊喜。在TDD技能中加入的一条指令，原本没指望它会特别遵循，即如果发现编写想要的测试很困难，这可能意味着需要“在做饭前先打扫厨房”。Claude真的把这一点记在了心上，它经常会停下来询问是否应该先打扫厨房，而且很多时候确实应该这么做。

【TDD技能的效果】

还没有让智能体100%地编写出可接受的测试，差距还很大。但TDD技能效果很好，已经成为进行任何更改的默认方式。将TDD和测试设计原则与AI结合能取得如此好的效果并不奇怪，AI生产力的最大提升来自于将AI与几十年前发现的、至今仍然适用且无论出现何种新技术都永远有用的永恒原则相结合。

【作者信息】

Jason Swett是 [Code with Jason播客] 的主持人，[《专业Rails测试》] 的作者，也是 [SaturnCI] 的创建者。SaturnCI [jason@saturnci.com] 16601 Myers Lake Ave Sand Lake, Michigan 49343