
本文探讨了在java和mockito中,当被测试类内部实例化了依赖对象时,如何模拟该依赖对象方法返回值的挑战。我们将解释直接模拟的局限性,并提供一种通过引入依赖注入(如`supplier`)来重构代码以提升可测试性的解决方案。教程还将涵盖测试中模拟对象的最佳实践和注意事项。
在单元测试中,我们经常需要模拟(mock)依赖对象的行为,以隔离被测试单元。然而,当依赖对象在被测试类内部被实例化时,传统的Mockito模拟方法会失效。考虑以下示例代码:
class A {
public String foo() {
return "Real A's foo";
}
}
class B {
public A foo() {
return new A(); // B的foo方法内部创建并返回A的实例
}
}
class SomeClass {
public void doSomeThing() {
B b = new B(); // SomeClass内部创建B的实例
A a = b.foo();
System.out.println(a.foo());
}
}在这种结构中,SomeClass直接在doSomeThing方法内部创建了B的实例,而B的foo方法又内部创建了A的实例。当尝试对SomeClass进行测试时,我们可能会尝试以下方式来模拟A的行为:
import org.junit.jupiter.api.Test;
import org.mockito.Mock;
import org.mockito.InjectMocks;
import org.mockito.Mockito;
import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;
class SomeClassTest {
@Mock
A aMock; // 尝试模拟A
@InjectMocks
SomeClass someClass;
@Test
void testDoSomeThing() {
// 期望aMock的foo方法返回特定值,但这种模拟不会生效
Mockito.when(aMock.foo()).thenReturn("Mocked A's foo");
// 执行doSomeThing方法
assertDoesNotThrow(() -> someClass.doSomeThing());
// 实际上,doSomeThing内部创建的是真实的A和B,aMock并未被使用
}
}上述测试尝试通过@Mock A aMock来模拟A,但这种方式是无效的。原因在于,SomeClass内部通过new B()创建了一个真实的B对象,进而B的foo()方法也返回了一个真实的A对象。Mockito无法拦截或替换这些在被测试类内部通过new关键字创建的实例。SomeClass与B之间,以及B与A之间,存在紧密的耦合,它们依赖于具体的实现而非抽象。
要解决这个问题,核心思想是解耦:将被测试类内部创建依赖对象的职责转移出去,使其能够通过外部注入的方式获得依赖。这通常通过依赖注入(Dependency Injection, DI)模式实现。
我们可以通过引入一个工厂或Supplier接口来提供B的实例,而不是在SomeClass内部直接创建它。这样,在测试时,我们就可以注入一个提供模拟B对象的Supplier。
import java.util.function.Supplier;
class SomeClass {
// 使用Supplier来延迟和抽象B的创建
private final Supplier<? extends B> bFactory;
// 推荐的构造函数:通过Supplier注入B的创建逻辑
public SomeClass(final Supplier<? extends B> bFactory) {
this.bFactory = bFactory;
}
// 可选的无参构造函数,用于兼容旧代码或简化生产环境的实例化
// 在实际项目中,也应尽量通过DI框架管理依赖,避免手动new SomeClass()
public SomeClass() {
this(B::new); // 默认使用B的真实构造函数
}
public void doSomeThing() {
B b = this.bFactory.get(); // 从工厂获取B的实例
A a = b.foo();
System.out.println(a.foo());
}
}在这个重构后的SomeClass中:
现在,有了重构后的SomeClass,我们就可以在测试中轻松地注入模拟的B实例,进而控制A的返回行为。
import org.junit.jupiter.api.Test;
import org.mockito.Mockito;
import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;
class SomeClassTest {
@Test
void testDoSomeThingWithMocks() {
// 1. 模拟A对象
final A aMock = mock(A.class);
// 配置aMock的行为,例如当调用aMock.foo()时返回特定值
when(aMock.foo()).thenReturn("Mocked A's foo from test");
// 2. 模拟B对象
final B bMock = mock(B.class);
// 配置bMock的foo()方法,使其返回我们模拟的aMock
when(bMock.foo()).thenReturn(aMock);
// 3. 创建一个Supplier,使其在调用get()时返回bMock
// 这样,当SomeClass请求B的实例时,会得到我们的bMock
final SomeClass someClass = new SomeClass(() -> bMock);
// 4. 执行被测试方法
assertDoesNotThrow(() -> someClass.doSomeThing());
// 验证bMock的foo方法是否被调用
Mockito.verify(bMock).foo();
// 验证aMock的foo方法是否被调用
Mockito.verify(aMock).foo();
}
}通过这种方式,我们成功地控制了SomeClass内部对B和A的依赖,使得测试可以完全隔离并验证SomeClass自身的逻辑。
尽管上述解决方案能够实现对内部实例化对象的模拟,但测试中出现“Mock返回Mock”(即when(bMock.foo()).thenReturn(aMock))的模式通常被认为是不良实践。
推荐做法: 如果可能,应尽量避免Mock返回Mock。更好的设计通常意味着:
本教程中采用的Supplier注入模式是依赖注入的一种形式。依赖注入是提升代码可测试性、可维护性和灵活性的关键设计模式。它使得:
从代码设计初期就考虑如何管理依赖至关重要。避免在类内部直接实例化复杂的、带有外部依赖的对象。相反,应通过以下方式引入依赖:
当被测试类内部实例化了依赖对象时,传统的Mockito模拟无法直接生效。解决此问题的核心在于通过重构代码,引入依赖注入模式(如Supplier),将被测试类与依赖对象的具体实例化解耦。虽然“Mock返回Mock”的模式可以实现功能,但在实际开发中应谨慎使用,并优先考虑更简洁、更健壮的设计。最终,良好的代码可测试性源于优秀的设计实践,即从一开始就考虑如何管理和注入依赖。
以上就是Mockito实践:如何模拟方法返回的对象并重构提升可测试性的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号