Robert C. Martin极少使用Mock工具的理念及替代方案技术问询

一、Uncle Bob观点的核心含义 #

Robert C. Martin（Uncle Bob）提出极少使用Mock工具，本质是反对过度依赖Mock带来的维护负担：

• 他认为随着系统规模增长，为失败的单元测试更新Mock依赖会变得异常繁琐，甚至让测试成为重构的阻碍。
• 他建议自行编写test doubles（测试替身），核心目的是通过手动实现替身的成本，倒逼开发者尽量编写低依赖、高内聚的代码——能避免引入不必要的协作类（collaborators）就尽量避免，从根源减少测试中需要Mock的场景。

二、面对“必需依赖”的应对思路 #

在遵循组合优于继承、依赖注入的实践中，Mock看似必不可少，但Uncle Bob的思路不是完全摒弃依赖，而是优化依赖的设计和测试策略：

• 窄接口设计：为依赖定义只满足当前类需求的窄接口（Role Interface），而非大而全的通用接口。这样即使依赖内部实现变化，只要接口契约不变，测试替身就无需修改。
• 优先用轻量级真实依赖：如果依赖本身无副作用、易实例化（比如简单的数据转换类），直接用真实对象做测试，比Mock更可靠，也省去Mock的维护成本。
• 分层测试：单元测试聚焦单一类的核心逻辑，多协作类的交互逻辑交给集成测试或组件测试，无需在单元测试中Mock所有依赖。

三、避免测试脆弱性的编码风格 #

要同时保持松耦合和避免协作类带来的测试脆弱，可参考这些实践：

• 测试行为而非实现：单元测试关注类的输入输出和业务行为，而非内部调用细节。比如不要测试“是否调用了依赖的某个方法”，而是测试“输入X后是否得到预期的输出Y”——这样即使内部依赖的调用逻辑变化，只要业务行为不变，测试就不会失效。
• 稳定测试边界：把测试边界划在稳定的业务接口上，而非易变的实现细节。比如针对服务类的业务方法写测试，而非私有方法或依赖的内部方法。
• TDD的落地优化：在TDD过程中，先写测试再写代码，会自然引导你设计更易测试的代码——比如拆分复杂逻辑为小的、低依赖的类，减少不必要的协作。
• Test Data Builder模式：针对复杂的依赖对象，用Builder模式快速构建测试用实例，比Mock更灵活，也能减少Mock的维护成本。

内容的提问来源于stack exchange，提问作者gbro3n