本文介绍如何使用 Mockito 的 doAnswer 模拟既返回值又修改传入对象状态（如设置 ID）的 DAO 方法，解决因仅 mock 返回值导致业务逻辑分支无法覆盖的问题。
本文介绍如何使用 mockito 的 `doanswer` 模拟既返回值又修改传入对象状态（如设置 id）的 dao 方法，解决因仅 mock 返回值导致业务逻辑分支无法覆盖的问题。
在单元测试中，当被测方法依赖于一个既返回结果又修改输入对象状态的 DAO 方法（例如：插入记录后将生成的主键 ID 赋值给传入的 DTO），仅用 when(...).thenReturn(...) 是不够的——它只能控制返回值，无法复现原方法对参数对象的“副作用”（side effect），从而导致后续逻辑（如 if (input.getId() != null) 分支）永远不执行。
此时，应使用 Mockito 的 doAnswer()，它允许你在 mock 方法被调用时自定义完整的行为逻辑：获取传入参数、修改其状态、再返回预期结果。
✅ 正确做法：使用 doAnswer 模拟副作用
@Test
public void testCreateSomething_WithIdSetOnInput() {
// Given
Dao dao = mock(Dao.class);
RecordDto input = new RecordDto();
input.setName("test");
input.setId(null); // 确保初始状态为 null
Integer generatedId = 1001;
int rowsUpdated = 1;
// When: 使用 doAnswer 定义完整行为
doAnswer(invocation -> {
RecordDto dto = invocation.getArgument(0, RecordDto.class);
dto.setId(generatedId); // ✅ 模拟真实 dao.createRecord 中的副作用
return rowsUpdated; // ✅ 同时返回行数
}).when(dao).createRecord(any(RecordDto.class));
// 执行被测方法
createSomething(input);
// Then: 验证副作用生效 & 业务逻辑触发
assertThat(input.getId()).isEqualTo(generatedId);
// （可进一步验证 doSomething 是否被调用，例如通过 spy 或 verify）
}? 关键点说明：
- any(RecordDto.class) 在 when(...) 中需与 doAnswer 配合使用；若需匹配特定实例（如原始 input），则应传入该引用（但注意：doAnswer 会直接修改它，适用于本场景）。
- invocation.getArgument(0, RecordDto.class) 安全获取第一个参数，类型安全且避免强制转换。
- 副作用（dto.setId(...)）和返回值（return rowsUpdated）在同一回调中完成，精准复现真实方法行为。
⚠️ 注意事项与设计建议
-
避免在生产代码中过度依赖参数副作用：当前设计使 createRecord 同时承担“创建”与“赋值”双重职责，增加了耦合与测试复杂度。更推荐的演进方向是：
// 推荐：返回新对象或封装结果，保持纯函数特性 public CreateResult createRecord(RecordDto input) { int id = executeInsert(input); return new CreateResult(id, 1); } // 或直接返回新 DTO（含 ID），输入 DTO 不变这样测试只需 when(dao.createRecord(...)).thenReturn(...)，无需 doAnswer，更易读、易维护、线程安全。
慎用 doAnswer 的副作用范围：确保只修改传入的 DTO 实例，不要意外影响其他测试状态；必要时可在 answer 中克隆对象以隔离副作用。
-
Mockito 版本兼容性：上述写法兼容 Mockito 2.x 和 3.x；若使用 Mockito 4+，可改用 Lambda 简化：
doAnswer(invocation -> { invocation.getArgument(0, RecordDto.class).setId(generatedId); return rowsUpdated; }).when(dao).createRecord(any());
总之，doAnswer 是应对“有状态副作用”的有力工具，但应视其为过渡方案——长远来看，重构为无副作用、职责单一、易于测试的接口设计，才是提升代码健壮性与可维护性的根本之道。
