用途
TDD Bug Fix 技能用于以测试驱动开发的方式修复缺陷。它遵循一个前提：当缺陷存在清晰且成本低廉的测试路径时，应在改动生产代码之前，先让损坏的行为变成可执行的测试。其目标是建立一个聚焦的回归测试——在修复前失败、修复后通过。
该技能的使用时机有明确限制：仅在用户明确要求 TDD、失败测试或回归测试时使用，或者当缺陷具有明显且成本低廉的本地测试目标时使用。
主要能力
- 判断何时适合编写失败测试，何时不适合。
- 在适合时，指导编写最小、聚焦、能捕捉该缺陷的回归测试。
- 在不适合时，改用最接近的可执行回归检查。
- 提供完整的工作流步骤与护栏，避免为测试而测试或修改测试以迎合错误实现。
使用方式
该技能按以下工作流执行：
- 理解缺陷：识别预期行为、当前行为、受影响路径以及最小可观察复现。
- 选择最窄的可执行检查：优先使用该代码路径已有的最近单元、组件、集成或回归测试。如果没有明显的实用测试路径，不要为了满足工作流而从零创建测试。
- 先写会失败的测试：添加最小的聚焦测试，该测试本应能捕捉到该缺陷。测试应编码预期行为，而不是镜像当前实现。
- 修复前运行新测试：确认它因预期原因失败。如果它通过或因无关原因失败，应在编辑实现之前修正测试或复现。
- 修复缺陷：做最小的生产变更以满足预期行为，同时保持附近的契约不变。
- 重跑回归测试：确认测试现在通过。
适用场景
当用户明确要求 TDD、失败测试或回归测试时，或当缺陷存在明显且成本低廉的本地测试目标时，应使用该技能。
限制
该技能明确不强制测试。以下情况应跳过新增测试，改用最接近的有效验证方式：
- 可用测试需要大范围测试框架搭建。
- 需要脆弱 mock。
- 依赖缓慢的端到端基础设施。
- 依赖仅生产环境状态。
- 复现步骤模糊。
- 会造成大量无关夹具变动。
失败测试不切实际时的替代方案
使用最接近的可执行回归检查，例如：定向脚本、手动复现命令、浏览器自动化、快照对比、日志断言或聚焦集成检查。
优先选择不新增测试，而不是糟糕的测试。糟糕的测试包括：主要测试 mock、编码当前实现细节、依赖时序或无关全局状态、为小修复需要昂贵基础设施，或在证明修复后立即被删除。
护栏
- 不要仅为了匹配错误实现而修改测试。
- 不要削弱现有断言，除非预期行为确实已改变且原因清晰。
- 保持回归测试聚焦于该缺陷，避免大范围夹具变动或无关覆盖率扩张。
- 如果缺陷是不稳定的，尽可能使测试确定化，并记录正在锁定的信号。
- 如果缺陷暴露了更广泛的失败类别，先落地聚焦的回归路径，再考虑额外的同类覆盖。
最终回复
报告证据，而不仅仅是结果：
- 指出修复前失败的测试或可执行检查及其产生的失败。
- 指出修复后通过的测试运行及所执行的附近验证。
- 如果无法展示修复前失败证据，说明原因并描述所使用的最近回归检查。
关于本技能
本技能标识为 tdd，来源为 mariusflorescu/pstack-t3。该技能的中文介绍基于其英文说明整理，未提供额外收费、价格或平台信息。