beaver-tdd

Files (1)

• SKILL.md

SKILL.md (first lines)

# 测试驱动开发

TDD 是 红→绿 循环：先写一个失败的测试，再写让它通过的最少代码，循环往复。本 skill 是让该循环产出值得保留的测试的参照——什么是好测试、测试在哪做、反模式、循环的规则、证据门禁。

## 什么是好测试

测试验证**行为**，而非实现细节。代码的内部结构可以变；只要行为不变，测试不应碎——这是测试能在重构中存活的根基。

断言里的期望值必须来自**独立的真实来源**——已知正确的字面量、worked example、规范——绝不能用与被测代码相同的方式重算，否则测试按构造即通过，永远无法与代码不一致：

```typescript
// BAD: expected value recomputed the way the code computes it
expect(add(a, b)).toBe(a + b);

// GOOD: expected value is an independent, known literal
expect(add(2, 3)).toBe(5);
```

## 测试在哪做

测试在你选择的**功能边界**进行——某个函数、模块、子系统，凡能观察行为且无需深入内部的地方。动手写测试之前，显式声明你要测试的边界及理由。

原则：**最小耦合 + 精确锁定行为**。问自己：这个测试是否只关心一个具体行为？重构不改行为时它是否继续通过？若测试绑定了内部实现细节（私有方法名、内部数据结构形状、协作者的具体调用），重构即碎——那就是实现耦合，见反模式。

## 反模式

- **与实现耦合**——模拟内部协作者、测试私有方法，或通过旁路渠道进行验证（例如绕过接口直接查询数据库）。识别信号：当你重构代码但行为并未改变时，测试却挂了。
- **同义反复**——断言以与代码相同的方式重新计算期望值（例如 `expect(add(a, b)).toBe(a + b)`、以同样手法手工生成的快照、或断言一个常量等于它自身），因此它按构造就必然通过，永远不可能与代码不一致。期望值必须来自独立的真理来源——一个已知正确的字面量、一个经过验证的示例，或者规范文档。
- **水平切片**——先写所有测试，再写所有实现。批量测试验证的是_想象出来的_行为：你测试的是事物的_形态_而非面向用户的行为，测试对真实变化变得麻木，而且你在还没理解实现之前就锁定了测试结构。相反，应该采用**垂直切片**的方式工作——一个测试 → 一个实现 → 重复，每个测试都是一颗**曳光弹**，它会对上一轮循环教给你的东西做出响应。

## 循环的规则

- **红先于绿。** 先写失败的测试，再只写让它通过的最少代码。不预判未来的测试、不加投机功能。
- **一次一个切片。** 一个边界、一个测试、一个最小实现，每轮循环。

## 证据门禁

你在完成报告中必须包含以下三项证据，缺一不可：

1. **声明的测试边界 + 理由** （来自边界声明）
2. **红失败证据** （实现前的失败测试输出）
3. **绿通过证据** （实现后的测试通过输出）

```
--- 证据门禁 ---
边界: <文件:行号 或 函数签名>
理由: <为什么选这个边界>
红:   <实现前的失败测试输出>
绿:   <实现后的测试通过输出>
-----------------
```

证据门禁是完成条件——报告缺少任何一项，视为任务未完成。

From 418-teapot/ZooKeeper, MIT.

More from 418-teapot/ZooKeeper