TDD 精通

为什么测试经常变成维护负担

很多团队写了测试，但测试变得脆弱、慢、且掩盖 bug。开发者为了覆盖率写测试，测试通过但删掉代码也通过（tautological tests）。缺乏纪律，跳过 TDD 的 Red 阶段，直接写实现代码。

核心循环与工程实践

TDD Mastery 回归经典的 Red-Green-Refactor 循环。

• Red: 先写一个失败的测试定义期望行为。
• Green: 写最小代码让测试通过。
• Refactor: 在测试绿灯下清理代码。

每个循环控制在 2-10 分钟。
在结构上，强制使用 Arrange-Act-Assert 模式，命名遵循 test___ 或 it("should when ")。
针对不同语言：

• Jest / Vitest: 推荐 vi.fn() 或 jest.fn() 做 mock，优先依赖注入，beforeEach 隔离状态。
• pytest: 使用 pytest.raises 处理异常，conftest.py 共享 fixture，用 @pytest.mark.slow 标记慢测试。
• Go: 默认使用表驱动测试，t.Helper() 辅助工具函数。

测试分层建议遵循 70% 单元、20% 集成、10% E2E 的比例。

边界与避坑指南

虽然强调覆盖率（CI 强制 80% line coverage），但核心是测试行为而非刷数字。
Mock 应限制在边界（HTTP、DB、FS、Clock），不要 mock 被测单元本身。仓库层优先使用 fake 而非 mock。
最后，坚决避免以下反模式：

• 测试实现细节而非行为
• 删掉代码测试依然通过
• 测试间共享可变状态
• 忽略 flaky tests
• 直接测试私有方法