单元测试是保障代码质量的关键环节。随着系统架构日益复杂，测试替身（Test Double）技术已成为隔离被测对象依赖关系的核心手段。其中，mocking 与 stubbing 作为最常用的测试替身，虽常被混用，但其设计理念与应用场景存在本质差异。本文将系统解析这两种技术的定义、实践场景与实施策略。
1 核心概念辨析：理解测试替身的本质
1.1 Stubbing：预设响应的数据供给者
Stubbing专注于状态验证，其核心是通过预编程方式为被测对象提供预设的依赖响应。当调用依赖组件的特定方法时，stub会按测试用例设定返回固定结果，而无需关注方法是否被调用或调用次数。
典型应用场景：
数据库查询返回模拟数据
第三方API接口的固定响应
文件读取操作的模拟内容
例如，测试用户服务层查询功能时，可创建stub模拟数据访问层，预设其返回特定用户对象，从而在不连接真实数据库的情况下验证业务逻辑。
1.2 Mocking：行为验证的交互监听者
Mocking的核心在于行为验证。Mock对象不仅提供响应，更是具备断言能力的智能代理，会记录测试过程中与其发生的所有交互，并在测试结束时验证这些交互是否符合预期，包括方法调用次数、参数匹配、调用顺序等。
关键特征：
显式设置预期行为模式
自动记录交互过程
内置验证机制检查调用合规性
例如，测试订单提交服务时，可创建mock对象模拟支付网关，并预设"processPayment方法应被精确调用一次且参数金额匹配"的预期，从而验证业务流程中关键环节的完整性。
2 实战对比：选择技术的决策框架
2.1 基于测试目标的选型标准
选择mocking或stubbing应基于测试的核心验证目标：
适用stubbing的场景：
测试逻辑仅依赖依赖组件的返回值
需要模拟各种不同的响应状态（成功、异常、超时等）
测试数据转换或计算逻辑
依赖组件不稳定或执行缓慢
适用mocking的场景：
需要验证对象间的协作协议
确保特定方法以正确参数和顺序被调用
验证非功能性交互（如缓存命中、日志记录）
测试命令式操作（如通知发送、状态更新）
2.2 代码示例：同一场景的两种实现
考虑用户注册服务，需在创建用户后发送欢迎邮件：
// 使用Stubbing测试业务逻辑
@Test
public void whenRegisterUser_thenShouldCreateUser() {
EmailServiceStub emailStub = new EmailServiceStub();
UserRepository userRepo = new UserRepository();
UserService service = new UserService(userRepo, emailStub);
User user = service.register("test@example.com", "password");
assertNotNull(user);
assertEquals("test@example.com", user.getEmail());
// 不验证邮件发送行为，仅关注用户创建结果
}
// 使用Mocking验证协作行为
@Test
public void whenRegisterUser_thenShouldSendWelcomeEmail() {
EmailServiceMock emailMock = mock(EmailService.class);
UserRepository userRepo = new UserRepository();
UserService service = new UserService(userRepo, emailMock);
service.register("test@example.com", "password");
// 验证协作行为：欢迎邮件必须被发送一次
verify(emailMock, times(1)).sendWelcomeEmail("test@example.com");
}3 最佳实践：避免测试替身的常见陷阱
3.1 适度使用原则：测试替身的风险管控
过度使用mocking和stubbing会带来测试脆弱性、维护成本增加等问题，需遵循以下准则：
控制测试替身的使用范围：
仅对跨边界依赖（外部系统、数据库、网络服务）使用替身
避免对系统内部组件（如领域对象、工具类）过度使用mock
优先考虑真实对象，仅在必要时引入测试替身
保持测试的语义清晰：
为stub和mock对象使用描述性命名
将测试数据准备与断言逻辑分离
避免在单个测试中混合多种验证策略
3.2 测试金字塔中的合理定位
在测试金字塔体系中，mocking和stubbing主要应用于单元测试层，以创建快速、隔离的测试环境。随着测试层级上升至集成测试和端到端测试，应逐步减少测试替身的使用比例，转向真实组件集成验证。
分层策略：
单元测试层：广泛使用stubbing和mocking实现隔离测试
集成测试层：有限使用stubbing模拟不稳定外部依赖
系统测试层：基本不使用测试替身，全面验证真实系统集成
4 进阶应用：现代测试框架的支持
4.1 主流框架功能对比
现代测试框架为mocking和stubbing提供了丰富支持：
4.2 架构模式的影响
系统架构设计直接影响测试替身的使用策略。在六边形架构中，通过依赖倒置原则，领域核心逻辑与外部依赖自然解耦，为测试替身的应用创造了理想条件。而在微服务架构中，mocking在测试服务间协作时发挥着更为关键的作用。
结语
掌握mocking与stubbing的正确使用是提升单元测试效能的核心技能。测试从业者应当深入理解两者的本质差异：stubbing关注状态，提供预设响应；mocking关注行为，验证交互协议。在实际项目中，基于测试目标合理选择技术策略，遵循适度使用原则，才能构建出既可靠又易维护的测试体系。随着测试经验的积累，开发团队应逐步建立统一的测试替身使用规范，让单元测试真正成为软件质量的坚实保障。