本文介绍如何通过重构设计（依赖注入）替代硬编码实例化，实现对私有 final 依赖类方法的可控模拟与异常验证，避免 mockedConstruction 的线程限制与断言失效问题。
本文介绍如何通过重构设计（依赖注入）替代硬编码实例化，实现对私有 final 依赖类方法的可控模拟与异常验证，避免 `mockedconstruction` 的线程限制与断言失效问题。
在实际测试中，当类 A 内部直接通过 new B(x, y) 初始化一个私有 final 字段 b 时，传统 Mock 工具（如 Mockito）难以在不侵入生产代码的前提下精准控制其行为——尤其在 Drools 规则等受限上下文中调用 someMethod() 时，我们既需跳过真实远程调用，又需验证特定异常是否被正确抛出。
最推荐、最可持续的解决方案是面向测试的设计重构：将 B 的创建职责从 A 中解耦，改由外部注入。这不仅提升可测性，也符合单一职责与依赖倒置原则。以下是具体实现方式：
✅ 推荐方案：添加依赖注入构造函数（支持 Lombok 简化）
class A {
private final B b;
// 原有构造函数（保留向后兼容）
public A(String x, String y) {
this(new B(x, y)); // 委托给新构造函数
}
// 新增测试友好构造函数（package-private 或 public）
A(B b) { // package-private：仅限同包测试访问
this.b = Objects.requireNonNull(b);
}
public void someMethod() {
b.externalMethod();
}
}
配合 Lombok（推荐），可进一步简化为：
import lombok.RequiredArgsConstructor;
@RequiredArgsConstructor
class A {
private final B b; // final 字段自动注入
// 仅需一个构造函数，Lombok 自动生成含 B 参数的构造器
public A(String x, String y) {
this(new B(x, y));
}
public void someMethod() {
b.externalMethod();
}
}
✅ 测试示例：精准模拟与异常断言
@Test
void someMethod_throwsExpectedException_whenBThrows() {
// 1. 创建 mock 实例
B mockedB = Mockito.mock(B.class);
// 2. 配置行为：在 externalMethod 调用时抛出异常
doThrow(new RuntimeException("Simulated error"))
.when(mockedB).externalMethod();
// 3. 构造被测对象（注入 mock）
A a = new A(mockedB); // 使用依赖注入构造函数
// 4. 执行并验证异常
assertThatThrownBy(a::someMethod)
.isInstanceOf(RuntimeException.class)
.hasMessage("Simulated error");
}
⚠️ 注意事项：
- 避免滥用 mockedConstruction：它在多线程/并发测试中易冲突，且无法延迟配置行为（如 doThrow() 必须在 mock 实例创建后调用，而 mockedConstruction 的 lambda 在构造瞬间执行，导致异常提前抛出）。
- 优先考虑无 Mock 方案：若 B.externalMethod() 的异常可由输入参数 x/y 或配置触发（如连接超时、Mock Server 响应），应优先采用真实轻量级集成测试，增强可信度。
- 访问权限设计：若不希望暴露 public A(B)，可使用 package-private 构造函数（同一包下测试类可直接访问），兼顾封装性与可测性。
综上，与其绕过设计缺陷强行 Mock，不如借测试之名推动代码演进——一个小小的构造函数重构，换来的是清晰的依赖关系、可靠的异常验证能力，以及长期可维护的测试套件。
