tdd

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Test-Driven Development

测试驱动开发

Core Rule

核心规则

Work in vertical red-green-refactor slices:

RED: write one test for one observable behavior.
GREEN: implement the smallest production change that makes that test pass.
REFACTOR: clean up only while tests are green.

Do not write a batch of imagined tests before implementation. Each new test should respond to what the last cycle taught you about the actual behavior and interface.

以垂直的red-green-refactor切片方式开展工作：

RED：为一项可观测行为编写一个测试。
GREEN：实现能让该测试通过的最小生产代码变更。
REFACTOR：仅在测试全部通过的情况下进行代码清理。

不要在实现前批量编写预想的测试。每一个新测试都应基于上一轮循环中你对实际行为和接口的认知来制定。

Plaited Defaults

默认约定

Use
```
bun test
```
for targeted tests and
```
bun --bun tsc --noEmit
```
for the type gate.
Use
```
test
```
, not
```
it
```
, and organize with
```
describe
```
.
Prefer real dependencies and real runtime boundaries over mocks.
Mock only external boundaries such as remote APIs, time, randomness, or rare filesystem cases.
Avoid conditional assertions: assert the branch first, then assert branch-specific values.
Test both branches for conditionals, fallbacks, and error paths.
Exercise public interfaces and runtime contracts rather than private helpers.
Follow applicable repo skills and
```
AGENTS.md
```
rules for the touched area.

使用
```
bun test
```
进行针对性测试，使用
```
bun --bun tsc --noEmit
```
作为类型检查关卡。
使用
```
test
```
而非
```
it
```
，并通过
```
describe
```
组织测试结构。
优先使用真实依赖和真实运行时边界，而非模拟（mock）对象。
仅对外部边界进行模拟，例如远程API、时间、随机性或罕见的文件系统场景。
避免条件断言：先断言分支情况，再断言分支特定的值。
针对条件语句、回退逻辑和错误路径，测试两个分支的情况。
测试公共接口和运行时契约，而非私有辅助函数。
遵循受影响代码区域对应的仓库规范和
```
AGENTS.md
```
规则。

When Starting Work

开始工作前

Explore the codebase first. If the public interface, expected behavior, or risk boundary is discoverable from code, tests, or docs, use that evidence instead of asking the user.

Ask one concise question only when the decision cannot be discovered and a reasonable assumption would be risky. Include your recommended answer.

Before writing production code, identify:

the public interface or runtime boundary under test
the first observable behavior to prove
the targeted test command for the cycle
the broader validation needed before handoff

先探索代码库。如果公共接口、预期行为或风险边界可通过代码、测试或文档获知，则以此为依据开展工作，无需询问用户。

只有当无法通过现有信息做出决策，且合理假设存在风险时，才提出一个简洁的问题，并附上你的推荐答案。

在编写生产代码前，确定以下内容：

待测试的公共接口或运行时边界
首先要验证的可观测行为
当前循环使用的针对性测试命令
移交前所需的全面验证内容

Cycle Discipline

循环规范

For each behavior:

Add or update exactly one focused test.
Run the targeted test and confirm it fails for the intended reason.
Implement only enough code to pass.
Run the same targeted test and confirm it passes.
Refactor if useful, then rerun the affected tests.

If the test passes before production code changes, it is not a valid RED signal. Tighten the test, choose a different behavior, or explain why existing coverage already proves the behavior.

针对每一项行为：

添加或更新一个聚焦的测试。
运行针对性测试，确认其因预期原因失败。
仅实现足够让测试通过的代码。
再次运行同一针对性测试，确认其通过。
如有需要进行重构，然后重新运行受影响的测试。

如果在修改生产代码前测试就已通过，则这不是有效的RED信号。此时需收紧测试条件、选择另一项行为，或解释为何现有测试覆盖率已能验证该行为。

Reference Files

参考文件

references/tests.md: behavior-test examples and implementation-detail red flags
references/mocking.md: boundary-only mocking guidance
references/interface-design.md: testable public interface design
references/deep-modules.md: small interface, deep implementation guidance
references/refactoring.md: refactor checks to run after green

references/tests.md：行为测试示例及实现细节警示
references/mocking.md：仅针对边界的模拟指导
references/interface-design.md：可测试的公共接口设计指南
references/deep-modules.md：小接口、深实现的指导
references/refactoring.md：测试通过后需执行的重构检查