用途：为每次代码变更提供可运行的验证手段，确保新逻辑、缺陷修复和既有功能都有对应检查，从而提升代码质量与可靠性。适用于实现功能、修复缺陷、提高覆盖率以及实践 TDD 的场景。
主要能力与要求：
- 验证循环优先：新逻辑采用红-绿流程；缺陷修复先写失败的回归测试；其他变更至少跑既有测试套件。
- 红-绿-观察：必须实际运行测试并阅读失败输出，不能仅凭推理假定会失败。
- 可证伪的完成条件：实现前先写出一条可由测试或命令确认或否定的具体条件。
- 证据优于叙述：完成声明需附上测试运行结果、真实退出码或提交 SHA，重跑并引用输出。
工作流程：用 Glob 和 Grep 找出未测试代码；为公开函数写单元测试；覆盖边界与错误条件；测试外部依赖的集成；用 Chrome DevTools 做浏览器端 E2E 自动化、截图、Lighthouse 无障碍检查与性能分析；回归测试须复现缺陷、确认在当前代码下失败、修复后保持通过并留在套件中，不得删除或跳过。
TDD 默认采用红-绿-重构：先写一个描述单一行为的失败测试，再写最小实现使其通过，仅在套件全绿时清理结构，不新增行为。一个测试只描述一个行为；除一次性探索外，不写没有失败测试驱动的生产代码；不在同一提交中既重构又加行为。TDD 适合新业务逻辑、缺陷修复和输入输出契约清晰的代码；探索性原型、一次性脚本、UI 布局样式调整和生成样板可在形态稳定后补测试。
测试质量标准：确定性（不依赖时钟、随机值或不可控外部状态）、隔离性（不相互依赖或共享可变状态）、清晰性（测试名描述被测行为）。
限制：资料未提供具体安装命令、价格、平台支持范围或更多实现细节。