Back to Details

ds-tdd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

ds-tdd

ds-tdd

Make the bug executable before touching production code, so the fix is proven, not claimed.
在修改生产代码之前，先让 Bug 变得可执行，从而证明修复有效，而不是仅声称已修复。

Steps

步骤

  1. Pin down the bug: expected behavior, actual behavior, the code path, and the smallest way to reproduce it.
  2. Find the nearest existing test style for that code path. Use it. Do not build a new harness just for this.
  3. Write the smallest test that would have caught the bug. It checks intended behavior, not the current implementation.
  4. Run it. Show the output. It must fail, and fail for the bug, not for a typo or missing import. If not, fix the test first.
  5. Make the smallest production change that gives the intended behavior without breaking nearby contracts.
  6. Run the new test and the surrounding suite. Show the output.
  7. If a clean test is impractical (heavy setup, brittle mocks, production-only state), use the closest runnable check instead: a script, a repro command or a log check. Say why you skipped the test.
  1. 明确 Bug：预期行为、实际行为、代码路径，以及最小化复现方式。
  2. 找到该代码路径附近现有的测试风格并沿用。不要仅为此专门构建新的测试工具。
  3. 编写能够捕获该 Bug 的最小测试。测试应检查预期行为，而不是当前实现。
  4. 运行测试并展示输出。测试必须失败，而且必须是因为该 Bug 而失败，而不是因拼写错误或缺少导入而失败。否则，应先修复测试。
  5. 进行能够实现预期行为且不会破坏附近代码契约的最小生产代码变更。
  6. 运行新测试及其周边测试套件，并展示输出。
  7. 如果无法轻易完成干净的测试（例如环境配置繁重、Mock 脆弱或仅存在于生产环境中），则改用最接近的可运行检查：脚本、复现命令或日志检查。说明跳过测试的原因。

Stop when

停止条件

  • The new test failed before the fix and passes after it, both shown with output, and the surrounding suite passes.
  • Or after three fix attempts the test still fails. Stop, report what you learned and run /ds-unstick.
  • 新测试在修复前失败、修复后通过，并且两次都展示了输出，同时周边测试套件通过。
  • 或者经过三次修复尝试后，测试仍然失败。此时停止，报告已经发现的问题，并运行 /ds-unstick。

Rules

规则

  • Never edit a test to match a wrong implementation.
  • Do not weaken existing assertions without a clear, stated reason.
  • No test beats a bad test: one that mostly tests mocks, depends on timing, or would be deleted right after.
  • 绝不能修改测试以迎合错误的实现。
  • 不得在没有明确说明原因的情况下削弱现有断言。
  • 再糟糕的测试也不如没有测试：避免测试主要验证 Mock、依赖计时，或测试完成后就会被删除。