Back to Details

tdd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

TDD Bug Fix

TDD Bug修复

When fixing a bug with a clear, cheap test path, make the broken behavior executable before changing production code. The goal is a focused regression test that fails before the fix and passes after it.
Do not force a test when it would be impractical. If the available test would require broad harness setup, brittle mocks, slow end-to-end infrastructure, production-only state, vague reproduction steps, or large unrelated fixture churn, skip adding a new test and use the closest useful verification instead.
修复 bug 时，如果存在清晰且成本较低的测试路径，应在修改生产代码之前先将错误行为转化为可执行测试。目标是编写一个聚焦的回归测试，使其在修复前失败，并在修复后通过。
不要在实际不可行的情况下强行添加测试。如果可用测试需要大量测试框架配置、脆弱的 mock、缓慢的端到端基础设施、生产环境专属状态、模糊的复现步骤，或引发大量无关 fixture 变动，则不要添加新测试，而应采用最接近且有用的验证方式。

Workflow

工作流

  1. Understand the bug. Identify the intended behavior, current behavior, affected path, and smallest observable reproduction.
  2. Choose the narrowest executable check. Prefer the closest unit, component, integration, or regression test already used for that codepath. If no practical test path is obvious, do not create one from scratch just to satisfy the workflow.
  3. Write the failing test first. Add the smallest focused test that would have caught the bug. The test should encode intended behavior, not mirror the current implementation.
  4. Run the new test before fixing. Confirm it fails for the intended reason. If it passes or fails for an unrelated reason, correct the test or reproduction before editing the implementation.
  5. Fix the bug. Make the smallest production change that satisfies the intended behavior while preserving nearby contracts.
  6. Rerun the regression test. Confirm the test now passes.
  1. 理解 bug。 确认预期行为、当前行为、受影响路径以及最小可观察复现方式。
  2. 选择范围最窄的可执行检查。 优先使用该代码路径已有的最接近的单元、组件、集成或回归测试。如果没有任何明显的实用测试路径，不要仅为满足工作流而从头创建测试。
  3. 首先编写失败测试。 添加能够捕获该 bug 的最小聚焦测试。测试应编码预期行为，而不是复刻当前实现。
  4. 修复前运行新测试。 确认测试因预期原因而失败。如果测试通过或因无关原因失败，应先修正测试或复现方式，再修改实现。
  5. 修复 bug。 进行满足预期行为所需的最小生产代码改动，同时保持附近代码的契约不变。
  6. 重新运行回归测试。 确认测试现在能够通过。

If a Failing Test Is Impractical

如果失败测试不可行

Use the closest executable regression check instead: a targeted script, manual reproduction command, browser automation, snapshot comparison, log assertion, or focused integration check.
Prefer no new test over a bad test. A bad test is one that mostly tests mocks, encodes current implementation details, depends on timing or unrelated global state, needs expensive infrastructure for a small fix, or would be deleted immediately after proving the fix.
改用最接近的可执行回归检查：定向脚本、手动复现命令、浏览器自动化、快照比较、日志断言或聚焦的集成检查。
宁可不要添加新测试，也不要添加糟糕的测试。糟糕的测试通常主要测试 mock、编码当前实现细节、依赖时序或无关的全局状态、为小范围修复引入昂贵基础设施，或者在证明修复有效后就会被立即删除。

Guardrails

防护措施

  • Do not change tests merely to match a wrong implementation.
  • Do not weaken existing assertions unless the expected behavior has genuinely changed and the reason is clear.
  • Keep the regression test focused on the bug. Avoid broad fixture churn or unrelated coverage expansion.
  • If the bug is flaky, make the test deterministic where possible and document the signal being locked down.
  • If the bug exposes a broader class of failures, first land the focused regression path, then consider additional sibling coverage.
  • 不要仅仅为了让测试匹配错误实现而修改测试。
  • 除非预期行为确实发生了变化且原因明确，否则不要削弱现有断言。
  • 确保回归测试聚焦于该 bug。避免大范围 fixture 变动或无关的覆盖率扩展。
  • 如果 bug 存在偶发性，应尽可能让测试具备确定性，并记录所锁定的行为信号。
  • 如果该 bug 暴露出更大范围的同类故障，应先落地聚焦的回归测试路径，再考虑添加其他同类覆盖。

Final Response

最终响应

Report the evidence, not just the outcome:
  • Name the failing-before test or executable check and the failure it produced.
  • Name the passing-after test run and any nearby validation performed.
  • If failing-before evidence could not be demonstrated, state why and describe the closest regression check used instead.
报告证据，而不只是结果：
  • 说明修复前失败的测试或可执行检查，以及它产生的失败信息。
  • 说明修复后通过的测试运行，以及执行过的相关验证。
  • 如果无法证明修复前失败，应说明原因，并描述所采用的最接近的回归检查。