Back to Details

test-driven-development

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Test-Driven Development

测试驱动开发（TDD）

Use a few behavior tests through the public interface. This skill is opt-in when the user asks for TDD/test-first, or repository instructions require that cycle. Follow codebase-design for shared readability rules and when-to-write-tests for test scope.
通过公共接口编写少量行为测试。当用户要求使用 TDD/test-first，或仓库规范要求遵循该流程时，可选择启用本技能。通用可读性规则请遵循 codebase-design，测试范围请参考 when-to-write-tests。

When to use

适用场景

  • The user asked for TDD, test-first, or red-green-refactor
  • Repository instructions require a failing-test-first cycle for the change
  • 用户要求使用 TDD、test-first 或 red-green-refactor 开发模式
  • 仓库规范要求本次变更必须遵循「先写失败测试」的流程

When not to use

不适用场景

  • Ordinary implementation or refactors without a TDD request or requirement
  • Private helper moves, comment edits, or docs edits alone
  • A request for a contract test without a request or requirement for TDD; use when-to-write-tests to choose that test
  • "Every new function/method"
  • Edges an advisory invented that are not the contract
  • Existing tests already cover the public behavior
Default is no new test. Smoke the changed path. See 
when-to-write-tests
.
  • 无 TDD 相关请求或要求的普通实现或重构工作
  • 仅涉及私有辅助函数迁移、注释修改或文档编辑的工作
  • 仅要求编写契约测试但未要求使用 TDD 的请求；此类测试应使用 when-to-write-tests 决策
  • 「每个新函数/方法都要写测试」的情况
  • 由建议性规则衍生、不属于契约范围的边界场景
  • 现有测试已覆盖公共行为的情况
默认不新增测试，仅对变更路径进行冒烟测试即可，详见 
when-to-write-tests
。

What to write

测试编写要求

One (or a few) tests that walk the real path: input at the public boundary → through the system → observable result.
Good: seed the old inbound tables, apply the migration, list events, assert facts and metadata survived.
Bad: a test per helper, encoder, or bind-list rewrite.
Prefer real collaborators over mocks. Exercise the route/store/UI path for those contracts; test a public pure function through its inputs and outputs. Supporting notes: tests.md, mocking.md.
编写一个（或少量）覆盖真实执行路径的测试：从公共边界输入 → 经过系统处理 → 产生可观测结果。
正面示例：初始化旧的入队数据表、执行迁移、列出事件、断言数据内容和元数据均完整保留。
负面示例：为每个辅助函数、编码器或绑定列表的重写都单独编写测试。
优先使用真实协作对象而非 mock。针对契约测试路由/存储/UI 路径；通过输入输出来测试公共纯函数。补充说明：tests.md、mocking.md。

Where tests live

测试文件存放位置

Next to the source: 
foo.test.ts
beside 
foo.ts
. Do not create a separate top-level 
test/
or 
tests/
directory in a package for these.
Exception: an end-to-end test that spawns the real server or CLI, or spans packages, lives in the repo-root 
tests/
(for example 
tests/smoke.test.ts
).
与源码放在一起：
foo.test.ts
紧邻 
foo.ts
存放。不要在包内单独创建顶层的 
test/
或 
tests/
目录来存放这类测试。
例外情况：需要启动真实服务器或 CLI、或跨包的端到端测试，存放在仓库根目录的 
tests/
下（例如 
tests/smoke.test.ts
）。

Cycle (only when this skill applies)

开发流程（仅在本技能适用时遵循）

  1. Name one observable behavior in a sentence.
  2. Write one failing test through its public interface.
  3. Write the simplest complete implementation that makes it pass.
  4. Refactor only when it improves understanding; keep related logic together.
  5. Repeat for the next required behavior. Do not add tests for each new helper.
Include failure, completion, and cleanup behavior when the contract requires it; a public pure function does not need an application-wide E2E harness.
Do not delete working code to restart TDD. Outside a requested or required TDD cycle, use the repository's proportional validation policy.
  1. 用一句话描述一个可观测行为。
  2. 通过公共接口编写一个会失败的测试。
  3. 编写最简单的完整实现使测试通过。
  4. 仅在能提升代码可读性时进行重构；将相关逻辑聚合在一起。
  5. 对下一个所需行为重复上述步骤。不要为每个新增的辅助函数都添加测试。
若契约有要求，需覆盖失败、完成和清理行为；公共纯函数不需要全应用级别的 E2E 测试框架。
不要为了重启 TDD 流程而删除可正常运行的代码。在未请求或未要求 TDD 流程的场景下，遵循仓库的比例验证策略。

Conflicts

冲突处理

User instructions and repository requirements take precedence. Use 
when-to-write-tests
to avoid redundant tests, not to waive required public behavior or lifecycle coverage.
用户指令和仓库要求优先级更高。使用 
when-to-write-tests
的目的是避免冗余测试，而非免除所需的公共行为或生命周期覆盖要求。