技能介绍

写测试时很容易陷入三种乱象：一是先实现再补测试，Red-Green-Refactor 变成走过场；二是测试名含糊、共享状态，偶发失败难以定位；三是覆盖率只盯行数，边界条件没覆盖却仍算达标。

先稳住红绿重构的节奏

技能把核心循环拆成可执行步骤：先写一个失败测试定义行为（Red），再写最小实现让测试通过（Green），最后在测试保持绿灯的前提下重构（Refactor）。每个循环建议控制在 2–10 分钟，避免一次塞进过多需求。明确原则：不写没有失败测试的生产代码。

用统一的测试结构降低认知负担

无论使用 Jest / Vitest、pytest 还是 Go Testing，技能都强调 Arrange-Act-Assert 结构。命名上可用 test___ 或 it("should when ")，让“期望行为 + 触发条件”一眼可读。针对各框架给出约定：

Jest / Vitest：vi.fn() / jest.fn() 做 mock，优先依赖注入而非模块级 mock；共享准备放 beforeEach，禁止测试间共享可变状态。
pytest：异常用 pytest.raises；共享夹具放 conftest.py；慢测试用 @pytest.mark.slow 标注。
Go Testing：默认采用表驱动测试；工具函数中调用 t.Helper()；除非团队已在用，不新增 testify/assert 依赖。

把覆盖率和 Mock 边界说清楚

技能建议在 CI 中强制最低 80% 行覆盖率，同时关注分支覆盖；排除生成代码、类型定义和配置文件，不以凑数字为目标。测试分层目标比例为 70% 单元 + 20% 集成 + 10% E2E：单元测试快、零外部依赖；集成测试跨模块边界，可使用真实数据库或文件系统；E2E 覆盖完整用户流程。

Mock 只在边界进行：HTTP 客户端、数据库、文件系统、时钟等；不要 mock 被测单元本身；仓储层优先使用内存假实现（fakes）而非 mock；断言关注行为结果，而非 mock 调用次数；用 t.Cleanup / afterEach 重置共享 mock。

适用边界与注意点

技能偏向行为测试与工程约束，适合需要长期维护、多人协作的代码库；如果你的链路必须依赖真实环境做长时集成测试，可按项目情况调整单元/集成比例。同时提醒避免这些反模式：测试实现细节而非行为；删除代码后测试仍通过；测试间共享可变状态；对 flaky test 视而不见；直接测私有方法；用巨大 setup 淹没测试意图。