6.1 单元测试框架巡礼
本节摘要：主流语言各有几代单元测试框架，选型要看清每家的"主心骨"。本节按语言巡礼 Java、Python、JavaScript、Go、C#、PHP 的主力框架的核心约定，并给出一张按特性挑框架的对照表。
选框架不是拼信仰
"用 JUnit 还是 Jest"这类争论，多数时候是信仰之争，但框架之间的配方其实很清楚——每一家用自己的约定解决了"怎么发现测试、怎么写断言、怎么传参数"这三个基本问题。看懂了主心骨，选型就从"听说哪个好"变成"哪个顺手顺我团队"。
四门大事：发现 / 断言 / 参数化 / 并行
所有框架都绕着四件事打转，先立这个框架再来对照各家。
- 发现：框架靠什么找到测试——按文件名、按注解、还是按目录约定。
- 断言：怎么写"应该等于 X"——基础断言、流式断言还是可读的重写。
- 参数化：同一逻辑跑多组输入怎么省劲。
- 并行：多个测试能不能同时跑，加速回归。
主流框架的一页巡礼
| 语言 | 主力框架 | 主心骨 | 关键动作 |
|---|---|---|---|
| Java | JUnit 5 | 注解 + 断言库生态 | @Test、@ParameterizedTest |
| Java | TestNG | 更强的参数化与分组 | 数据提供者、组 |
| Python | pytest | 极简发现 + fixture | 函数即测试、conftest |
| JS/TS | Jest | 快照 + mock 一体化 | test()/it()、toMatchSnapshot |
| JS | Mocha+Chai | 灵活动手板 | describe()/it()、BDD 断言 |
| Go | testing | 标准库内建 | TestXxx + go test |
| C# | xUnit | 免配置惯例 | [Fact]、[Theory] |
| PHP | PHPUnit | 断言 + 数据提供者 | assertXxx、@dataProvider |
下面把各语言框架的"发现逻辑"画成一幅全景图，方便你目录结构摆对。
挑框架的三条真功夫
第一，看它给你的签名可读性——断言写完读起来像不像一句业务句话（契合 BDD 味道）；第二，看参数化处理得顺不顺手，因为第 2.5 节那个"堆样例"的病，正靠参数化缓解；第三，看隔离与替身是内建还是靠外部库（回看第 6.2 节）。信鄙视链是没有意义的，能把四件大事做成顺手，才是适合自己的。
一个真实切换案例
背景：某 Python 团队从 unittest 迁移到 pytest，理由是 unittest 的类式组织太重，参数化绕。
操作：切到 pytest 后，测试直接写成顶层函数、参数化用装饰器一行搞定，conftest 统一收拢 fixture。
结果：同一批用例代码量降了近一半，全局 fixture 一处维护，新人上手更快，commit 前的绿灯恢复得也更快。
解读：换框架的收益主要来自"顺手"，而非"更高级"。变式：Java 团队类似地从手写断言迁向 JUnit5 参数化，用的也是同一套判断——哪家把四件大事做得省心。
签约定与生态也要一起掂
四件大事之外，还有个常被忽略的维度——框架所在生态的大小和活跃度。一个框架再顺手，如果生态冷清、文档不全、遇到问题时找不到人讨论，维护成本会悄悄反超。反之，生态蓬勃的项目即便某处不那么顺手，靠社区插件的便利店也能补齐。选型时把"是否有一圈热闹的插件 + 官方文档 + Stack Overflow 讨论"当成第五件大事来掂，能省掉不少半夜踩坑的工夫。
再补一个越老越容易犯的提醒：别为"面子"跟风迁移。看到一个框架突然流行就全仓搬迁，往往只是把一段还不错的测试体系用更高的迁移成本重写一遍。迁移前先回答第 1.4 节那种成本账——新框架带来的收益（顺手、可读、参数化方便）是否真的超过搬迁的一次性成本。若旧框架只是"没毛病但不热门"，往往不值得动。
一个容易踩的跨境陷阱
还有一个新团队常踩的坑：把不同语言的框架"经验"直接平移到另一门语言。比如在 JS 里习惯了 Jest 的快照断言，换到 Java 就纠结"怎么没有快照"，或者在 Python 里习惯了 pytest 顶层函数，到了要求包结构的 C# 里硬把测试写成顶层函数。每个框架的"发现逻辑"牢牢长在其语言习惯里（注解 vs 函数命名 vs 属性），强行平移往往水土不服。切换语言时，与其逆着框架的惯例硬来，不如先顺着它的主心骨写，习惯了再谈风格统一。
把它放进"工具都不是银弹"的大容器
最后把这一节放进第 6 章的大容器里去理解：好框架能省很多力，但框架不等于测试能力，更不等于质量。即使用了全栈最顺手的框架，若你还在写"断言恒真""堆样例"的反模式（见 2.5），或者把不该有的依赖硬拗到单元层，那么换再好的框架也只是把坏测试写得更好看、跑得更快罢了。反过来说，一个看着朴素的框架，只要你能把第 2 章的铁律、第 3 章的接缝方法用对，它照样能产出高质量测试。
所以选框架时别把"哪家强"当成唯一的仗，真正值钱的是"同一个人用这套框架能把几件大事做得多顺手"——框架只是工具，能不能做出健康的质量，决定权始终在你对分层、断言、隔离这些基础功的掌控上。框架是得力的助手，不是你可以依赖的拐杖；助手用得顺手是福气，把命运全押在拐杖上才是危险。
一个"最小可行工具集"的提议
如果你是小白或小团队，不想在一堆框架里选择困难，给你一个好用的"最小可行工具集"思路：每个语言先锁定"一个默认框架 + 一套默认替身方式 + 一个默认脚手架"，先把这套用熟，再谈横向对比和升级。过度纠结"把每个库都摸一遍"是对注意力的浪费，你真正缺的不是更多工具，而是把已有的默认组合熟练应用起来的次数。等它成了肌肉记忆，你会发现框架之争自然淡出，剩下的全是文档质量和口碑的次要取舍。
本节要点回顾
- 四件大事：发现 / 断言 / 参数化 / 并行，拿来当比对手牌。
- 看主心骨：各自靠注解、函数名、后缀、属性来发现。
- 三条真功夫：签名可读、参数化顺手、隔离替身内建还是外接。
- 反鄙视链：顺手才是王道，好框架省心不累赘。
- 切换看收益：换框架要能降代码量、提速反馈才值。