在软件开发中，单元测试是保障代码质量的重要环节，而Mock（模拟）对象的使用又是单元测试中一个常见的技巧。然而，正如你所困惑的，过度Mock确实会导致测试变得异常复杂，甚至与实际运行逻辑脱节，维护成本急剧上升。那么，究竟应该遵循哪些原则来判断何时需要Mock，何时又不需要呢？这里有一些我个人在实践中总结的经验和判断方法，希望能帮助你理清思路。
核心原则：测试你的代码，而不是它的依赖
首先，我们要明确单元测试的核心目标：测试**系统被测单元（System Under Test, SUT）**的独立行为和逻辑。我们关心的是SUT在给定输入下，是否产生了预期的输出或状态变化，而不是SUT所依赖的外部组件是如何工作的。当一个依赖会干扰SUT的独立性、可控性或测试速度时，我们就应该考虑Mock它。
何时需要Mock依赖？
以下是一些常见的需要Mock依赖的场景：
外部服务或资源交互（External Services/Resources）
- 数据库（Database）：读写数据库是典型的外部依赖，通常速度慢且有副作用。在单元测试中，我们不希望真的去连接数据库，而是Mock其仓储层（Repository）接口，确保SUT调用数据库操作时能得到预设的数据或执行预期的行为。
- 网络API调用（Network API Calls）：调用远程API不仅慢，而且可能不稳定，还依赖于网络连接。Mock这些API接口是必须的，以隔离网络问题。
- 文件系统（File System）：读写文件或目录同样慢且有副作用。Mock文件操作接口可以避免实际的文件I/O。
- 消息队列（Message Queues）/缓存（Caches）：与MQ或缓存系统的交互也属于外部依赖。
非确定性组件（Non-Deterministic Components）
- 时间（Time）：例如
System.currentTimeMillis()或DateTime.now()。如果SUT的逻辑依赖于当前时间，而你希望测试某个特定时间点的行为，就需要Mock时间服务。 - 随机数生成器（Random Number Generators）：为了测试可重复性，我们会Mock随机数生成器，让它返回预设的序列。
- 时间（Time）：例如
耗时或资源密集型操作（Slow/Resource-Intensive Operations）
- 即使不是严格意义上的外部服务，但某些本地计算或初始化过程可能非常耗时，影响测试速度。如果这些操作与SUT的核心逻辑无关，也可以考虑Mock。
有副作用的组件（Components with Side Effects）
- 如果一个依赖操作会导致系统状态发生难以回滚或观察的变化（例如发送邮件、修改全局配置），那么在单元测试中Mock它是一个好选择，以避免不必要的副作用。
你无法控制的依赖（Dependencies You Don't Own/Control）
- 当你的代码依赖于第三方库中复杂的、你无法修改的组件，或者你的团队中其他成员尚未完成的模块时，Mock可以让你专注于测试自己的代码。
何时不需要Mock依赖？
过度Mock的危害在于它会使测试变得脆弱，当依赖的实现细节改变时，即使SUT的行为没有变化，测试也可能失败。这违背了单元测试的初衷。所以，以下情况应尽量避免Mock或谨慎Mock：
简单的数据对象/值对象（Simple Data/Value Objects）
- 例如DTO（数据传输对象）、POJO（普通Java对象）等，它们只包含数据和简单的Getter/Setter方法，没有复杂的行为逻辑。Mock这些对象是多余的，直接创建真实对象即可。
SUT的内部核心逻辑部分（Core Logic of SUT）
- 如果一个依赖是SUT实现其核心业务逻辑的内在组成部分，而不是其交互的“外部边界”，那么Mock它可能会导致你实际上没有测试到SUT的关键行为。你的测试可能变成了“测试Mock对象是否被调用”，而不是“SUT是否正确处理了业务逻辑”。
- 反模式警示：如果你的测试需要Mock SUT内部调用的私有方法，这通常是代码设计不佳的信号。SUT应该通过其公共接口与依赖交互，而不是通过Mock内部私有逻辑。
轻量级、无状态、确定性的内部服务（Lightweight, Stateless, Deterministic Internal Services）
- 如果一个内部服务是纯粹的计算器、辅助工具类，它不涉及外部交互，不产生副作用，并且在给定输入下总是产生相同输出，那么直接使用真实对象通常是更好的选择。它们运行速度快，使用真实对象能更好地反映SUT与这些辅助组件的实际协作。
测试的粒度问题
- 如果你发现为了测试一个SUT，需要Mock大量的依赖，这可能意味着你的SUT承担了过多的职责（高耦合），或者你的测试粒度过大，它更像一个集成测试而不是单元测试。在这种情况下，应该考虑重构SUT以降低其耦合度，或者使用更高层次的测试（如集成测试）来验证多组件协作。
判断的黄金法则：依赖反转原则与可测试性设计
更好的代码设计能自然地减少Mock的复杂性。遵循依赖反转原则（Dependency Inversion Principle, DIP），通过接口而非具体实现来依赖，并使用**依赖注入（Dependency Injection, DI）**框架，可以使SUT更容易地在测试中被注入Mock依赖。
思考以下问题来辅助判断：
- 隔离性：这个依赖是否会破坏我测试SUT的隔离性？（例如，它会修改全局状态、访问外部资源吗？）
- 速度：这个依赖的真实实现是否会显著拖慢我的单元测试？
- 确定性：这个依赖的真实行为是否是不可预测的或非确定性的？（例如，随机数、当前时间）
- 副作用：这个依赖的真实操作是否会产生我不想在测试中发生的副作用？
- 关注点分离：这个依赖是我SUT的内部实现细节，还是它协作的外部伙伴？我们通常Mock外部伙伴。
总结
Mocking是一把双刃剑。恰当使用可以大幅提升单元测试的效率和可靠性；滥用则会引入不必要的复杂性和脆性。核心在于理解单元测试的隔离性要求，以及SUT与依赖之间的边界。当你面临选择时，回想一下这些原则，并权衡利弊，你就能做出更明智的判断。
记住：测试的是行为，而非实现细节。当Mock让你能更好地专注于SUT的行为时，它就是有益的。当它让你不得不关注被Mock对象的内部调用细节时，你可能就走错了方向。
