本文探讨了在%ignore_a_1%单元测试中，当被测类内部创建依赖对象时，如何有效模拟该对象方法返回值的挑战。通过引入依赖注入和`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注入到SomeClass中，我们允许外部提供B实例的创建逻辑。
ImagetoCartoon
一款在线AI漫画家，可以将人脸转换成卡通或动漫风格的图像。
106 查看详情
import java.util.function.Supplier;class SomeClass { private final Supplier bFactory; // 注入B的工厂 /** * 构造函数：接受一个Supplier来提供B实例的创建逻辑。 * 这是实现依赖注入的关键。 * @param bFactory 提供B实例的Supplier */ public SomeClass(final Supplier 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实例。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等依赖注入机制，我们可以有效地解耦组件，从而在单元测试中精确控制并模拟内部创建对象的行为。这不仅提高了代码的可测试性，也促使我们编写出更灵活、更易于维护的模块化代码。然而，在实践中，我们应当时刻警惕“模拟返回模拟”等可能导致测试脆弱的反模式，并始终坚持“为可测试性而设计”的原则，以构建健壮、可维护的软件系统。
以上就是Java单元测试：解耦内部依赖以模拟方法返回对象的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1089776.html
微信扫一扫 
支付宝扫一扫 
