
本文旨在解决在单元测试中,当被测试类内部创建了依赖对象,且需要模拟该依赖对象方法返回的另一个对象时遇到的挑战。通过深入探讨紧耦合问题,并提出使用依赖注入(通过`supplier`接口)重构代码的策略,文章详细演示了如何有效地模拟内部创建对象的行为,从而实现更彻底和可维护的单元测试。
在进行单元测试时,我们经常需要模拟外部依赖的行为,以确保只测试当前类的逻辑。然而,当被测试类(System Under Test, SUT)内部直接实例化其依赖对象时,传统的模拟方法往往会失效。本文将以一个具体的Java示例,深入探讨这一问题,并提供基于重构和依赖注入的解决方案。
考虑以下Java类结构: SomeClass在其doSomeThing方法中创建了B的实例,然后调用b.foo(),该方法返回一个A的实例,最后又调用了a.foo()。
class SomeClass {
public void doSomeThing() {
B b = new B(); // B的实例在内部创建
A a = b.foo();
a.foo();
}
}
// 假设 A 和 B 是其他类
class A {
public void foo() { /* 实际逻辑 */ }
}
class B {
public A foo() { return new A(); /* 实际逻辑 */ }
}我们的目标是测试SomeClass.doSomeThing()方法,并希望模拟b.foo()返回的A对象,甚至模拟A对象上的foo()方法。
初学者可能会尝试以下测试方法:
import org.junit.jupiter.api.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.Mockito;
import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;
class SomeClassTest {
@Mock
A aMock; // 尝试模拟 A
@InjectMocks
SomeClass someClass;
@Test
void testInitialAttempt() {
// 尝试模拟 aMock 的行为
Mockito.when(aMock.foo()).thenReturn( /* some value or do nothing */ );
// 执行被测方法
assertDoesNotThrow(() -> someClass.doSomeThing());
}
}然而,上述测试将无法达到预期效果。原因在于SomeClass内部通过new B()直接创建了B的实例。这意味着,在someClass.doSomeThing()执行时,它调用的是B的真实实现,而不是一个Mockito模拟对象。因此,b.foo()将返回一个真实的A对象,而不是我们通过@Mock A aMock创建的模拟对象,对aMock的配置也就毫无作用。
问题的根源在于SomeClass与B的紧密耦合。SomeClass直接依赖于B的具体实现,并且控制了B实例的生命周期(通过new B())。这种设计模式使得我们无法在不修改SomeClass代码的情况下,替换掉B的真实行为,从而无法有效地进行单元测试。为了实现可测试性,我们需要解耦SomeClass和B的创建过程。
要解决这一问题,我们需要对SomeClass进行重构,使其能够“注入”B的创建方式,而不是在内部硬编码。一种常见的做法是使用依赖注入,特别是对于对象创建的场景,可以注入一个工厂或Supplier。
我们将SomeClass重构如下,引入一个Supplier<B>来提供B的实例:
import java.util.function.Supplier;
class SomeClass {
private final Supplier<? extends B> bFactory;
// 构造函数,允许外部注入 B 的创建方式
public SomeClass(final Supplier<? extends B> bFactory) {
this.bFactory = bFactory;
}
// 为了向后兼容或简化迁移,可以提供一个无参构造函数,
// 它使用默认的 B 实例创建方式。在生产代码中,
// 推荐始终使用带参数的构造函数。
public SomeClass() {
this(B::new);
}
public void doSomeThing() {
B b = this.bFactory.get(); // 从 Supplier 获取 B 实例
A a = b.foo();
a.foo();
}
}通过这种方式,SomeClass不再直接创建B的实例,而是通过bFactory.get()方法获取。在生产环境中,这个Supplier可以提供真实的B实例;而在测试环境中,我们可以提供一个返回模拟B实例的Supplier。
有了重构后的SomeClass,我们现在可以编写一个有效的单元测试来模拟b.foo()返回的A对象。
import org.junit.jupiter.api.Test;
import org.mockito.Mockito;
import java.util.function.Supplier;
import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;
class SomeClassRefactoredTest {
@Test
void testWithRefactoredClass() {
// 1. 模拟 A 对象
final A aMock = mock(A.class);
// 配置 aMock 的行为,例如当 aMock.foo() 被调用时
// 这里只是示例,实际可能需要thenReturn()一个值或doNothing()
when(aMock.foo()).thenAnswer(invocation -> {
System.out.println("aMock.foo() was called!");
return null; // 或者返回一个具体值
});
// 2. 模拟 B 对象
final B bMock = mock(B.class);
// 配置 bMock 的行为:当 bMock.foo() 被调用时,返回 aMock
when(bMock.foo()).thenReturn(aMock);
// 3. 创建一个 Supplier,使其在被调用时返回 bMock
final Supplier<B> bSupplierMock = () -> bMock;
// 4. 使用这个 Supplier 实例化 SomeClass
final SomeClass someClass = new SomeClass(bSupplierMock);
// 5. 执行被测方法并验证
assertDoesNotThrow(() -> someClass.doSomeThing());
// 可选:验证 mock 对象的交互
Mockito.verify(bMock).foo(); // 验证 bMock 的 foo() 方法被调用
Mockito.verify(aMock).foo(); // 验证 aMock 的 foo() 方法被调用
}
}在这个测试中:
尽管上述方法能够有效解决问题,但需要注意以下几点:
当被测试类内部创建了其依赖对象,并且需要模拟该依赖对象方法返回的另一个对象时,直接的Mockito模拟会失效。核心解决方案在于重构被测试类,引入依赖注入机制(如通过Supplier接口),将依赖对象的创建过程外部化。这使得测试能够提供模拟的依赖对象,从而实现对被测试类行为的有效隔离和验证。虽然“模拟返回模拟”在某些情况下是必要的,但应谨慎使用,并优先考虑更简洁、更少耦合的测试策略。一个可测试的设计是高质量软件的重要标志。
以上就是如何在Mockito中模拟方法返回的对象:重构与依赖注入实践的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号