本文介绍一种无需 powermockito 或重构为依赖注入的前提下，通过受保护构造函数实现对内部新建对象（如 client）的可控模拟测试方案，兼顾可测性与代码简洁性。
本文介绍一种无需 powermockito 或重构为依赖注入的前提下，通过受保护构造函数实现对内部新建对象（如 client）的可控模拟测试方案，兼顾可测性与代码简洁性。
在单元测试中，当被测类（如 MyClass）自行实例化其依赖对象（例如在构造器或私有方法中调用 setupClient() 创建 Client 实例），而该依赖未通过构造参数或 setter 注入时，标准 Mockito 无法直接拦截或替换该内部对象——因为 Mockito 只能作用于已存在的、可引用的 mock 实例，而非“凭空出现”的真实对象。
此时，最轻量、符合 Mockito 原则且无需引入额外框架的解决方案是：扩展类的构造能力，提供一个受保护（protected）的构造函数，允许测试时传入预设的 mock 对象。这既不破坏原有 API 兼容性（公有无参构造器仍保留），又为测试打开了可控入口。
具体实现分为两步：
- 改造被测类：保留默认构造器，同时新增一个 protected 构造器接收依赖对象，并将原初始化逻辑提取为可复用的 setupClient() 方法：
public class MyClass {
private final Client someClient;
// 原有公有构造器：保持向后兼容
public MyClass() {
this.someClient = setupClient();
}
// 新增受保护构造器：专供测试使用
protected MyClass(Client client) {
this.someClient = Objects.requireNonNull(client, "client must not be null");
}
private Client setupClient() {
// 原有客户端构建逻辑，如 new OkHttpClient() 或配置工厂调用
return new DefaultClient(); // 示例：真实实现
}
public void methodIWantToTest(String requestString) {
this.someClient.makeApiCall(requestString);
// 其他业务逻辑...
}
}
- 编写测试类：在测试中创建 Client 的 mock 实例，并通过新构造器注入；随后使用 Mockito.when(...) 精确配置其行为：
public class MyClassTest {
private MyClass SUT;
private Client mockClient;
@BeforeEach
void setUp() {
mockClient = Mockito.mock(Client.class);
SUT = new MyClass(mockClient); // 使用受保护构造器注入 mock
}
@Test
void testMethodIWantToTest() {
// 配置 mock 行为：当任意字符串参数调用 makeApiCall 时返回预设响应
Mockito.when(mockClient.makeApiCall(Mockito.anyString()))
.thenReturn(new ApiResponse(200, "{\"status\":\"ok\"}"));
// 执行被测方法
SUT.methodIWantToTest("GET /users");
// 验证行为是否按预期发生
Mockito.verify(mockClient).makeApiCall("GET /users");
// 可进一步断言业务结果（如状态码、数据解析等）
}
}
✅ 优势说明：
- 完全基于标准 Mockito，零外部依赖；
- 不违反单一职责原则，不强制要求 Spring/Guice 等 DI 容器；
- protected 访问级别确保生产代码无法误用，仅测试包可见（需保证测试类与被测类同包，或使用模块化开放）；
- 保持类内聚性——setupClient() 逻辑仍封装在类内部，仅构造入口更灵活。
⚠️ 注意事项：
- 若类已声明为 final，此方案不可行（需配合 @ExtendWith(MockitoExtension.class) 和 @MockedConstruction（Mockito 4.11+）替代，但属进阶场景）；
- protected 构造器应显式校验入参（如 Objects.requireNonNull），避免测试中传入 null 导致 NullPointerException 掩盖真实问题；
- 此法本质是“测试友好型设计”，并非妥协，而是主动提升可测性——它比反射设值（ReflectionTestUtils.setField）更稳定，比 PowerMockito 更安全。
总结而言，面对“内部创建依赖”的测试困境，与其绕过 Mockito 机制强行 mock 类本身，不如以最小侵入方式开放测试入口。这种构造器重载策略，是平衡可测性、可维护性与框架约束的务实之选。
