Back to Details

poteto-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时，在修改生产代码前先让失效行为可执行。目标是编写一个针对性的回归测试，在修复前失败，修复后通过。
不要在不切实际的情况下强行编写测试。如果可用的测试需要大量的测试框架配置、脆弱的模拟对象、缓慢的端到端基础设施、仅生产环境可用的状态、模糊的复现步骤，或者需要修改大量无关的测试夹具，则跳过添加新测试，转而使用最接近的有用验证方式。

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.
  7. Run nearby validation. Run relevant adjacent tests, type checks, lint, or scenario checks when the change has broader risk.
  1. 理解bug。明确预期行为、当前行为、受影响路径以及最小可观测的复现方式。
  2. 选择最精简的可执行检查。优先选择该代码路径已在使用的最贴近的单元测试、组件测试、集成测试或回归测试。如果没有明显可行的测试路径，不要为了遵循流程而从头创建测试。
  3. 先编写失败的测试。添加能够发现该bug的最小化针对性测试。测试应编码预期行为，而非镜像当前实现。
  4. 修复前运行新测试。确认测试因预期原因失败。如果测试通过或因无关原因失败，在修改实现前先修正测试或复现步骤。
  5. 修复bug。做出最小化的生产代码变更，既要满足预期行为，又要保留周边代码的契约。
  6. 重新运行回归测试。确认测试现在已通过。
  7. 运行周边验证。当变更存在更广泛风险时，运行相关的相邻测试、类型检查、代码扫描或场景检查。

If a Failing Test Is Impractical

当编写失败测试不切实际时

Do not silently skip the regression step. Before fixing, explicitly explain why a failing test is impossible or not worth the cost, then choose the closest executable regression check available. Examples include 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.
不要悄悄跳过回归步骤。在修复前，明确说明为什么无法编写失败测试或不值得投入成本，然后选择最接近的可用可执行回归检查方式。例如针对性脚本、手动复现命令、浏览器自动化、快照对比、日志断言或聚焦式集成检查。
宁可不要新测试，也不要编写糟糕的测试。糟糕的测试指的是主要测试模拟对象、编码当前实现细节、依赖时序或无关全局状态、为小修复需要昂贵基础设施，或者在验证修复后会立即被删除的测试。

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.
  • Do not add tests when the practical signal is weak; use manual or scripted verification and say why.
  • 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本身；避免大量修改测试夹具或扩展无关的测试覆盖范围。
  • 当实际测试价值很低时，不要添加测试；使用手动或脚本化验证，并说明原因。
  • 如果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.
报告验证证据，而非仅说明结果：
  • 说明修复前失败的测试或可执行检查，以及它产生的失败信息。
  • 说明修复后通过的测试运行情况，以及执行的任何周边验证。
  • 如果无法展示修复前的失败证据，说明原因，并描述转而使用的最接近的回归检查方式。