单元测试的本意是验证某一段逻辑的正确性，但现实中很多代码并不是孤立运行的：它要读数据库、调用远程接口、发消息队列、读写文件。一旦这些外部依赖出问题，测试就会跟着遭殃。于是Mock技术和依赖隔离手段就成了每个认真做测试的工程师绕不开的课题。这篇文章把这两个话题掰开揉碎，讲清楚它们各自的适用场景、常见坑点以及落地方案。
为什么外部依赖会毁掉单元测试
先来分析一下问题的根源。单元测试讲究快速、稳定、可重复，而外部依赖天然和这三点作对。一个真实调用远程接口的测试，网络抖动就可能让它失败；一个依赖数据库的测试，需要在测试前准备数据、测试后清理数据，稍有不慎就互相污染。更麻烦的是，如果测试逻辑本身没问题，却因为外部服务挂了而报红，开发者会逐渐对测试失去信任，最后干脆跳过测试。
速度是另一个大问题。一次真实的HTTP请求可能要几百毫秒，一次数据库查询加上连接建立可能更久，而一次内存中的函数调用只有微秒级。当测试套件里有几十上百个用例都去真实调外部服务，跑一遍测试可能要十几分钟，这样的测试没人愿意频繁执行，也就失去了持续验证的价值。
还有一个容易被忽视的点：外部依赖让测试难以覆盖异常路径。比如支付接口的限流、超时、返回错误码，这些场景在真实环境里很难稳定复现，测试却恰恰需要覆盖它们。如果不把依赖隔离出来，这些分支几乎成了测试盲区。
Mock的基本用法与常见误区
Mock的核心思路很简单：用一个假的实现替换掉真实依赖，这个假实现的行为由测试代码完全控制。你可以指定它在被调用时返回什么值、抛出什么异常、被调用了几次。以Python为例，标准库自带的unittest.mock已经足够应对大多数场景：
from unittest.mock import Mock, patch
# 假设业务代码中有这样的调用
def get_user_balance(user_id):
resp = requests.get(f"https://api.ipipp.com/balance/{user_id}")
return resp.json()["balance"]
# 测试时用patch替换掉requests.get
@patch("__main__.requests.get")
def test_get_user_balance(mock_get):
mock_resp = Mock()
mock_resp.json.return_value = {"balance": 100}
mock_get.return_value = mock_resp
assert get_user_balance(42) == 100
mock_get.assert_called_once_with("https://api.ipipp.com/balance/42")这段测试运行时根本不会发起网络请求，毫秒级就能完成，而且可以随意构造各种返回值来驱动不同分支。类似的能力在Java里有Mockito，在JavaScript里有Jest的mock函数，思路都是相通的。
但Mock用不好反而会让测试变得脆弱。最常见的误区是过度Mock：把被测对象的所有 collaborator 全部替换掉，结果测试只验证了Mock对象之间的交互，没有验证任何真实逻辑，改一行实现代码测试照样通过，这样的测试形同虚设。经验法则是：只Mock那些跨越边界的依赖，比如网络、数据库、文件系统，业务对象之间的协作尽量用真实实现。
另一个误区是Mock了不该Mock的东西。有些代码直接在函数内部new出依赖对象或者硬编码了外部调用，Mock起来需要用patch这种比较侵入的手段，一旦重构，测试就大面积报错。这其实是在提醒你代码设计有问题，应该先做依赖隔离的重构。
依赖注入：让隔离从源头上变简单
与其测试时费劲地把依赖替换掉，不如在写代码时就让依赖可以从外面传进来，这就是依赖注入。把外部依赖抽象成接口或者函数参数，被测代码只依赖抽象而不依赖具体实现，测试时传入一个轻量的假实现即可：
// 定义抽象接口，业务逻辑只依赖这个抽象
public interface BalanceService {
BigDecimal getBalance(long userId);
}
// 业务类通过构造函数接收依赖
public class AccountManager {
private final BalanceService balanceService;
public AccountManager(BalanceService balanceService) {
this.balanceService = balanceService;
}
public boolean canWithdraw(long userId, BigDecimal amount) {
return balanceService.getBalance(userId).compareTo(amount) >= 0;
}
}
// 测试时传入手工编写的Stub实现
public class FakeBalanceService implements BalanceService {
@Override
public BigDecimal getBalance(long userId) {
return new BigDecimal("500");
}
}
@Test
public void testCanWithdraw() {
AccountManager manager = new AccountManager(new FakeBalanceService());
assertTrue(manager.canWithdraw(1L, new BigDecimal("300")));
}这种方式的优点是测试代码非常直白，不依赖任何Mock框架的魔法，重构时也更稳定。缺点是需要多写一些接口和假实现，对于小项目可能显得繁琐。实践中可以折中：核心业务依赖用接口抽象加依赖注入，边缘的、偶尔用到的依赖再借助Mock框架快速处理。
依赖注入还带来一个额外好处：不同的运行环境可以注入不同实现。生产环境注入真正调用远程服务的实现，本地开发时可以注入一个读本地文件或返回固定数据的实现，集成测试环境注入一个指向测试容器的实现。同一套业务代码无需修改就能在多种环境下运行，这正是隔离设计的价值所在。
分层测试策略：别把Mock当成唯一手段
Mock虽然好用，但整个测试体系不能全靠它。业界常说的测试金字塔给出了参考结构：底层是大量的单元测试，全部隔离外部依赖，追求速度和稳定；中间是一定数量的集成测试，使用真实的数据库或通过WireMock、testcontainers等工具搭建可控的外部服务，验证模块之间的协作；顶层是少量端到端测试，走真实链路，确保整体流程可用。
分层的关键在于让每类测试各司其职。单元测试负责把业务逻辑的分支覆盖穷尽，集成测试负责验证Mock掉的边界在真实对接时确实没问题，比如序列化格式、字段命名、认证头这些容易被Mock掩盖的细节。如果只写单元测试而跳过集成测试，很容易出现每个单元的测试都是绿的、拼起来却跑不通的尴尬局面。
最后总结几条实操建议：第一，先通过依赖注入把代码的可测试性设计好，Mock只是补充手段；第二，Mock的粒度对准边界，不要Mock被测对象自己内部的逻辑；第三，对被Mock的外部接口，安排对应的集成测试兜底，防止接口变更导致假通过；第四，持续关注测试执行速度，一旦某个用例开始依赖真实环境，及时把它挪到集成测试层。做到这几点，外部依赖就再也不是单元测试的绊脚石了。