本文介绍两种专业、可维护的方案解决“类在构造器中直接 new 依赖对象”导致难以单元测试的问题：一是通过构造函数注入实现可测性，二是对深层依赖（如 reader）进行接口抽象与替换，无需 mockito 即可完成高质量测试。
本文介绍两种专业、可维护的方案解决“类在构造器中直接 new 依赖对象”导致难以单元测试的问题：一是通过构造函数注入实现可测性，二是对深层依赖（如 reader）进行接口抽象与替换，无需 mockito 即可完成高质量测试。
在 Java 单元测试实践中，一个常见但棘手的问题是：当目标类（如 A）在字段声明处或构造器中直接调用 new D() 实例化依赖，而该依赖（D）自身又因读取文件等外部操作难以实例化时，传统 Mock 工具（如 Mockito）无法直接拦截 new 行为——因为 new D() 发生在被测类内部，非受控调用。
✅ 推荐方案一：重构为构造函数依赖注入（Dependency Injection）
这是最符合面向对象设计原则和测试友好的方式。将硬编码的 new D() 提升为构造参数，既解耦了依赖，又天然支持测试：
public class A {
private final D d;
// 主构造器：支持注入 mock 或真实依赖
public A(D d) throws FileNotFoundException {
this.d = Objects.requireNonNull(d);
}
// 无参构造器：保留原有使用方式（委托给主构造器）
public A() throws FileNotFoundException {
this(new D()); // 仍可运行于生产环境
}
}对应测试代码简洁清晰，无需反射或特殊工具：
@Test
void testWithMockedD() {
D mockD = mock(D.class);
// 可选：stub mockD 的行为，例如 when(mockD.someMethod()).thenReturn("value");
A tested = new A(mockD); // 直接注入，完全可控
// 执行待测逻辑并断言...
}⚠️ 注意：此方案需修改生产代码，但收益显著——提升可测性、可维护性与设计清晰度，是长期推荐的重构方向。
立即学习“Java免费学习笔记（深入）”；
Java注释规范Skills下载当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
✅ 推荐方案二：对深层依赖进行接口抽象（面向接口编程）
若暂时无法修改 A 类，可进一步优化 D 类的设计，将其对外部资源（如 Reader）的强依赖解耦为接口参数：
public class D {
private final Reader reader;
// 默认构造器：保持向后兼容
public D() throws FileNotFoundException {
this(new InputStreamReader(new FileInputStream("filePath")));
}
// 测试友好构造器：接收 Reader 接口
public D(Reader reader) {
this.reader = Objects.requireNonNull(reader);
}
// 其他业务方法中使用 this.reader...
}此时测试 A 无需任何 Mock 框架，仅需传入轻量、内存级的 StringReader：
@Test
void testWithInMemoryReader() throws Exception {
String testContent = "line1\nline2";
D d = new D(new StringReader(testContent));
A tested = new A(d); // 使用自定义 D 实例
// 执行业务逻辑验证...
}该方案的优势在于：
- 零 Mock 开销：避免 Mockito 的启动开销与学习成本；
- 高可靠性：基于真实类行为，而非模拟逻辑；
- 易于调试：所有对象均为真实实例，堆栈清晰。
? 总结与建议
| 方案 | 是否需改源码 | 是否需 Mock 框架 | 可维护性 | 推荐场景 |
|---|---|---|---|---|
| 构造函数注入（A(D d)） | ✅ 是（推荐重构） | ❌ 否 | ⭐⭐⭐⭐⭐ | 新项目、模块重构期、追求长期可测性 |
| 接口抽象（D(Reader r)） | ✅ 是（局部优化） | ❌ 否 | ⭐⭐⭐⭐ | 快速修复遗留代码、规避 FileInputStream 等硬依赖 |
切忌使用 FieldSetter、PowerMock 等反射/字节码工具强行绕过设计缺陷——它们虽能“解决问题”，却掩盖了架构脆弱性，增加技术债。真正的单元测试友好性，源于良好的设计：依赖应可插拔，资源访问应面向接口，构造逻辑应显式可控。
