testing

软件测试

先建立验证闭环

每项变更在完成前都要有可运行的检查：新逻辑采用先红后绿；修复 Bug 时，先让回归测试失败再让它通过；其他情况则运行现有测试套件。没有检查的变更不得交付。

先红、再绿、再观察，不要先红后绿就想当然：下方工作流中的「确认它会失败」以及 TDD 中的「观察它失败」步骤，意味着必须实际运行测试，并在动手修复或实现之前阅读失败输出——绝不要只靠推理认定「它肯定会失败」而跳过运行。

可证伪的完成条件：开始编写功能实现之前，先明确一个具体、可检查的完成条件——不能只是「现在应该能用了」，而必须是测试或命令可以确认或证伪的条件。

以证据为准，而非描述：完成声明的可信度取决于所引用的证据——粘贴的测试运行结果、实际退出代码、已推送的提交 SHA。描述代码现在应该如何运行并不算证据；重新运行检查并引用其输出才算。

MCP 工具

Chrome DevTools（端到端测试）：

• 自动化真实浏览器中的用户流程
• 捕获屏幕截图以进行视觉回归测试
• 运行 Lighthouse 进行无障碍测试
• 在测试运行期间分析性能

工作流

• 分析：使用 Glob 和 Grep 找出未经测试的代码
• 单元测试：覆盖所有公开函数
• 边缘情况：测试边界条件和错误情况
• 集成：测试外部依赖项
• 端到端测试：使用 Chrome DevTools 进行浏览器自动化
• 回归测试：添加一个能复现 Bug 的测试，确认它在当前代码上失败，然后修复——之后要让测试持续通过并保留在测试套件中（绝不删除或跳过）

测试驱动开发

编写新逻辑时，默认采用红—绿—重构流程：

1. 红：在编写实现之前，针对一种行为编写一个失败的测试。
2. 绿：编写让该测试通过所需的最少代码。
3. 重构：仅在测试套件全部通过时整理代码结构——此步骤不得添加新行为。

• 每个测试只验证一种行为——如果描述测试时需要用「并且」，就拆分测试。
• 没有失败测试驱动时，绝不编写生产代码；探索性试验或临时探索除外（合并前删除这些代码或补上测试）。
• 不要在同一次提交中既重构又添加行为；切换角色前先确保测试全部通过并提交（参见 code-quality.md 中的 Two Hats Rule）。

适合默认采用 TDD 的情况：新业务逻辑、Bug 修复（先编写回归测试，观察它失败，再进行修复）以及输入／输出契约明确的任何代码。

不适合采用 TDD 的情况：探索性试验、临时脚本、UI 布局／样式调整以及生成的样板代码——等结构稳定后再编写测试。

测试质量标准

确定性

测试每次都必须产生相同结果——不得依赖墙上时钟时间、随机值或不受控的外部状态。

隔离性

测试之间不得相互依赖，也不得共享可变状态。

清晰性

测试名称应描述所测试的行为，而不只是函数名称。