
本文探讨了在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();
}
}在这个重构后的版本中:
通过上述重构,我们现在可以轻松地在单元测试中模拟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();
}
}在这个测试案例中:
尽管上述方法能够有效解决内部依赖的模拟问题,但仍需注意以下几点,以确保测试的健壮性和代码的可维护性:
当被测类内部直接创建依赖对象时,传统的模拟方法往往无法奏效。通过对代码进行重构,引入Supplier等依赖注入机制,我们可以有效地解耦组件,从而在单元测试中精确控制并模拟内部创建对象的行为。这不仅提高了代码的可测试性,也促使我们编写出更灵活、更易于维护的模块化代码。然而,在实践中,我们应当时刻警惕“模拟返回模拟”等可能导致测试脆弱的反模式,并始终坚持“为可测试性而设计”的原则,以构建健壮、可维护的软件系统。
以上就是Java单元测试:解耦内部依赖以模拟方法返回对象的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号