本文探讨了在java单元测试中，当被测类内部创建依赖对象时，如何有效模拟该对象方法返回值的挑战。通过引入依赖注入和`supplier`模式进行代码重构，文章展示了如何解耦紧密耦合的组件，从而实现对内部创建对象行为的精确模拟。同时，文章强调了在测试中避免“模拟返回模拟”的实践建议，以确保测试的健壮性和可维护性。
理解问题：内部依赖的测试困境
在编写单元测试时，一个常见且棘手的场景是，当被测试的类（例如SomeClass）在其方法内部直接创建并使用其他类的实例（例如B），并且我们希望模拟该内部创建对象（B）所返回的另一个对象（A）的行为时。这种模式导致了被测类与它所依赖的具体实现之间的高度耦合，从而严重阻碍了单元测试的进行。
考虑以下代码结构：
class SomeClass {
public void doSomeThing() {
B b = new B(); // B的实例在内部创建
A a = b.foo(); // 我们希望模拟a的行为
a.foo();
}
}
class B {
public A foo() {
// 实际的业务逻辑，返回一个A的实例
return new A();
}
}
class A {
public void foo() {
// A的业务逻辑
}
}在这种情况下，如果尝试使用Mockito等模拟框架直接模拟A，例如通过@Mock注解，并期望它在SomeClass中被使用：
import org.junit.jupiter.api.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;
class SomeClassTest {
@Mock
A aMock; // 尝试模拟A
@InjectMocks
SomeClass someClass; // 注入SomeClass实例
@Test
void test() {
// 配置aMock的foo()方法行为
// Mockito.when(aMock.foo()).thenReturn(something); // 如果A.foo()有返回值
// 执行被测试的方法
assertDoesNotThrow(() -> someClass.doSomeThing());
}
}这样的测试是无法成功的。核心原因在于，SomeClass内部通过new B()创建了一个B的实际实例，而不是一个模拟实例。因此，当b.foo()被调用时，它将执行真实B对象的方法，返回一个真实的A对象（或者抛出空指针异常，如果B.foo()返回null），而不是我们通过@Mock注解创建并配置的aMock。这明确指出SomeClass与B之间存在紧密的耦合，使得SomeClass对B的具体实现产生了依赖，从而降低了代码的可测试性。
立即学习“Java免费学习笔记（深入）”；
解决方案：重构以实现依赖注入
要解决这种紧密耦合带来的测试难题，核心思想是重构代码，使SomeClass不再直接负责B实例的创建，而是通过依赖注入的方式获取B的实例或其创建方式。这样，在测试时，我们就可以注入一个模拟的B实例或一个能提供模拟B实例的工厂。
一种有效的重构方式是引入Java 8的Supplier接口。Supplier是一个函数式接口，它不接受任何参数，但会返回一个结果。通过将Supplier<B>注入到SomeClass中，我们允许外部提供B实例的创建逻辑。
import java.util.function.Supplier;
class SomeClass {
private final Supplier<? extends B> bFactory; // 注入B的工厂
/**
* 构造函数：接受一个Supplier来提供B实例的创建逻辑。
* 这是实现依赖注入的关键。
* @param bFactory 提供B实例的Supplier
*/
public SomeClass(final Supplier<? extends B> bFactory) {
this.bFactory = bFactory;
}
/**
* 无参构造函数：提供默认行为，便于现有代码迁移或生产环境使用。
* 默认使用B的无参构造函数创建B实例。
*/
public SomeClass() {
this(B::new);
}
public void doSomeThing() {
B b = this.bFactory.get(); // 通过Supplier获取B实例
A a = b.foo();
a.foo();
}
}在这个重构后的版本中：
- SomeClass不再直接调用new B()，而是持有一个Supplier<B>实例。
- bFactory.get()方法负责在运行时提供B的实例。
- 我们提供了一个带Supplier参数的构造函数，允许在测试时注入自定义的B创建逻辑（例如，一个返回模拟B对象的Supplier）。
- 为了不影响现有生产代码或简化迁移，我们还提供了一个无参构造函数，它默认使用B::new（即B类的默认构造函数）作为Supplier。
测试实践：模拟与验证
通过上述重构，我们现在可以轻松地在单元测试中模拟B和A的行为。
import org.junit.jupiter.api.Test;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;
class SomeClassTest {
@Test
void testDoSomeThingWithMocks() {
// 1. 模拟A对象
final A aMock = mock(A.class);
// 如果A.foo()有返回值，可以在这里配置aMock的行为
// when(aMock.foo()).thenReturn(someValue);
// 2. 模拟B对象
final B bMock = mock(B.class);
// 关键一步：配置bMock的foo()方法，使其返回我们模拟的aMock
when(bMock.foo()).thenReturn(aMock);
// 3. 创建SomeClass实例，注入一个Supplier，使其提供bMock
// 当SomeClass调用bFactory.get()时，会得到bMock
final SomeClass someClass = new SomeClass(() -> bMock);
// 4. 执行被测试的方法
assertDoesNotThrow(() -> someClass.doSomeThing());
// 5. 验证模拟对象的交互（可选但推荐）
// 验证bMock的foo()方法是否被调用
verify(bMock).foo();
// 验证aMock的foo()方法是否被调用
verify(aMock).foo();
}
}在这个测试案例中：
- 我们首先使用mock()方法创建了A和B的模拟对象 (aMock 和 bMock)。
- 关键一步是配置bMock.foo()方法，使其返回aMock。这样，当SomeClass通过bFactory.get().foo()获取A时，它实际上会得到我们模拟的aMock。
- 然后，我们通过带Supplier参数的构造函数创建SomeClass实例，传入一个Lambda表达式 () -> bMock。这个Supplier在被SomeClass调用get()方法时，会返回我们预设的bMock。
- 最后，执行someClass.doSomeThing()并验证其行为。assertDoesNotThrow用于确认方法执行过程中没有抛出预期之外的异常。
- 通过verify()方法，我们可以进一步验证模拟对象的方法是否按照预期被调用，增强测试的严谨性。
最佳实践与注意事项
尽管上述方法能够有效解决内部依赖的模拟问题，但仍需注意以下几点，以确保测试的健壮性和代码的可维护性：
- 避免“模拟返回模拟” (Mocks Returning Mocks)：在上述示例中，我们让bMock返回了aMock。这种“模拟返回模拟”的模式虽然在某些特定场景下可行，但通常被认为是代码异味的信号。它可能导致测试变得脆弱、复杂，并且与实现细节过度耦合。理想情况下，模拟对象应该返回简单的数据或行为，而不是另一个模拟对象。如果经常需要这样做，可能意味着被测试类的职责过于复杂，或者设计上存在改进空间。
- 设计可测试性：从一开始就将可测试性纳入设计考量，可以避免后续的重构工作。例如，使用工厂模式、抽象工厂模式或依赖注入框架（如Spring、Guice）来管理依赖的创建和生命周期，可以使代码更易于测试和维护。
- 接口优先原则：尽可能地针对接口而不是具体实现进行编程和模拟。如果B和A是接口，那么模拟它们的行为会更加灵活，且能更好地体现面向接口编程的优势。
- 测试粒度：单元测试应关注单个单元（通常是一个类或方法）的行为。如果一个测试需要模拟多个层次的依赖，可能意味着测试的粒度过大，或者被测试的单元职责过多，需要进一步拆分。
总结
当被测类内部直接创建依赖对象时，传统的模拟方法往往无法奏效。通过对代码进行重构，引入Supplier等依赖注入机制，我们可以有效地解耦组件，从而在单元测试中精确控制并模拟内部创建对象的行为。这不仅提高了代码的可测试性，也促使我们编写出更灵活、更易于维护的模块化代码。然而，在实践中，我们应当时刻警惕“模拟返回模拟”等可能导致测试脆弱的反模式，并始终坚持“为可测试性而设计”的原则，以构建健壮、可维护的软件系统。
