Back to Details

tdd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

TDD Bug Fix

TDD 缺陷修复

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.
当修复具备清晰、低成本测试路径的缺陷时，在修改生产代码前先让失效行为可执行。目标是创建一个聚焦的回归测试，在修复前失败，修复后通过。
若测试不切实际，则不要强行添加。如果可用测试需要大量的测试框架搭建、脆弱的模拟对象、缓慢的端到端基础设施、仅生产环境存在的状态、模糊的复现步骤，或大量无关的测试夹具变更，则跳过新增测试，改用最接近的有效验证方式。

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. 理解缺陷：明确预期行为、当前行为、受影响路径，以及最小可观测的复现方式。
  2. 选择最窄的可执行检查：优先选用该代码路径已在使用的最贴近的单元测试、组件测试、集成测试或回归测试。如果没有明显可行的测试路径，不要为了遵循流程而从头创建。
  3. 先编写失败的测试：添加能发现该缺陷的最小聚焦测试。测试应编码预期行为，而非镜像当前实现。
  4. 修复前运行新测试：确认测试因预期原因失败。如果测试通过或因无关原因失败，在修改实现前先修正测试或复现方式。
  5. 修复缺陷：做出满足预期行为的最小生产代码变更，同时保留周边代码约定。
  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.
  • 不要仅为匹配错误实现而修改测试。
  • 除非预期行为确实发生变化且原因明确，否则不要弱化现有断言。
  • 回归测试要聚焦于缺陷；避免大量测试夹具变更或无关的覆盖范围扩展。
  • 当实际测试价值不高时，不要添加测试；改用手动或脚本验证并说明原因。
  • 如果缺陷是偶现的，尽可能让测试确定化，并记录锁定的验证信号。
  • 如果缺陷暴露了更广泛的故障类型，先落地聚焦的回归测试路径，再考虑添加额外的同类覆盖。

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.
报告证据，而非仅结果：
  • 说明修复前失败的测试或可执行检查，以及其产生的失败信息。
  • 说明修复后通过的测试运行情况，以及执行的所有周边验证。
  • 如果无法展示修复前的失败证据，说明原因并描述改用的最接近的回归检查。