tdd

TDD 错误修复

本文适用于 TypeScript 资源及其 NUI。它们的测试会在资源的测试运行器中执行，并会模拟代码所调用的原生函数和 @overextended/ox_lib，因此不需要 FiveM 服务端。

修复错误时，如果有明确且成本低廉的测试路径，应在修改生产代码之前，先让错误行为能够通过测试复现。目标是编写一项针对性回归测试，在修复前失败、修复后通过。

不要在测试难以实现时强行添加测试。如果现有测试需要大范围搭建测试框架、脆弱的模拟、缓慢的端到端基础设施、仅生产环境才有的状态、含糊的复现步骤，或大量无关的测试数据变更，请跳过新增测试，改用最接近且有用的验证方式。

工作流

1. 了解错误。 明确预期行为、当前行为、受影响的路径，以及最小可观察复现。
2. 选择最精简的可执行检查。 优先使用该代码路径已有的最贴近的单元、组件、集成或回归测试。如果没有明显可行的测试路径，不要为了满足工作流而从头创建测试。
3. 先编写失败测试。 添加能够捕获该错误的最小针对性测试。测试应描述预期行为，而不是照搬当前实现。
4. 修复前运行新测试。 确认测试因预期原因失败。如果测试通过，或因无关原因失败，请先修正测试或复现，再修改实现。
5. 修复错误。 以最小的生产代码改动满足预期行为，同时保留相邻契约。
6. 重新运行回归测试。 确认测试现已通过。

如果失败测试难以实现

改用最接近的可执行回归检查：针对性脚本、通过 NUI 开发服务器执行的浏览器自动化、日志断言，或在错误属于类型错误时使用 tsc --noEmit。

宁可不新增测试，也不要编写糟糕的测试。糟糕的测试是指主要在测试模拟对象、照搬当前实现细节、依赖时间或无关的全局状态、为了小幅修复而需要昂贵基础设施，或在证明修复后会立即删除的测试。

注意事项

• 不要为了匹配错误的实现而修改测试。
• 除非预期行为确实发生了变化且原因明确，否则不要弱化现有断言。
• 让回归测试聚焦于该错误。避免大范围修改测试数据或扩展无关覆盖范围。
• 如果错误具有间歇性，请尽可能让测试保持确定性，并说明该测试锁定的行为信号。
• 如果该错误暴露出更广泛的一类故障，应先建立针对性的回归路径，再考虑增加其他同类覆盖。

最终回复

报告证据，而不仅仅是结果：

• 指明修复前失败的测试或可执行检查，以及它产生的失败结果。
• 指明修复后通过的测试运行，以及执行的任何相关验证。
• 如果无法展示修复前的失败证据，请说明原因，并描述所采用的最接近的回归检查。