tdd
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.
修有清晰、便宜测试路径的 bug 时，改生产代码前先让坏行为可执行。目标是聚焦的回归测试：修前失败，修后通过。
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.
不切实际就别硬测。若可用测试需要大范围 harness、脆弱 mock、慢端到端基建、仅生产态、模糊复现步骤，或大量无关 fixture 搅动，就别加新测试，改用最接近的有用验证。
Workflow
工作流
-
Understand the bug. Identify the intended behavior, current behavior, affected path, and smallest observable reproduction.
-
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.
-
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.
-
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.
-
Fix the bug. Make the smallest production change that satisfies the intended behavior while preserving nearby contracts.
-
Rerun the regression test. Confirm the test now passes.
-
理解 bug。 弄清预期行为、当前行为、受影响路径、最小可观察复现。
-
选最窄可执行检查。 优先该 codepath 已在用的最近单元/组件/集成/回归测试。没有明显实用路径，别为满足工作流从零造一个。
-
先写失败测试。 加能抓住 bug 的最小聚焦测试。测编码预期行为，别镜像当前实现。
-
修前跑新测试。 确认因预期原因失败。若通过或因无关原因失败，先改正测试或复现，再改实现。
-
修 bug。 做满足预期行为的最小生产改动，同时保住周边契约。
-
重跑回归测试。 确认现在通过。
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.
宁可没有新测试，也不要坏测试。坏测试：主要测 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.
-
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。避免大范围 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.
-
点名修前失败的测试或可执行检查，以及它产生的失败。
-
点名修后通过的测试跑，以及附近做的验证。
-
若无法展示修前失败证据，说明为什么，并描述改用的最接近回归检查。