所以，我欠吉姆道歉。 他编写了一个有效的模拟和JUnit测试，我在回顾中告诉他，我认为它没有达到他的预期。 当我错了时，这种情况对我来说就像是一个错误 。 称其为理想的意外副作用。

假设您有以下两类：

 public class Service { private String name; private Widget widget; public Service(String name, Widget widget) { this .name = name; this .widget = widget; } public void execute() { widget.handle(name); }  }  public interface Widget { void handle(String thing);  } 

那里没什么令人兴奋的…

现在，让我们尝试使用Mockito测试（此处为JUnit 5）测试服务：

 @ExtendWith (MockitoExtension. class )  class ServiceTest { @Mock private Widget widget; @InjectMocks private Service service = new Service( "Joe" , widget); @Test void foo() { service.execute(); verify(widget).handle( "Joe" ); }  } 

测试通过。 但是应该吗？

对我来说， @InjectMocks批注旨在作为一种工厂方法来创建依赖于模拟值的东西，在测试中用@Mock表示。 这就是我通常使用的方式，并且我也希望生态系统中的所有对象都是使用构造函数注入构建的。

这是一个很好的设计原则，但不是工具功能的定义！

应用此批注的外观与在注释字段的过程@InjectMocks ，并采取不同的路径，如果它的null比，如果它已经初始化。 对于null路径是一种声明式构造函数注入方法如此纯粹，我完全不认为注入模拟可能意味着对现有对象执行此操作。 该文档也不太清楚这一点。

• 如果没有对象，则@InjectMocks必须创建一个
  • 它使用可以提供的最大构造函数
• 如果有一个对象，它将尝试通过setter来填充模拟
• 如果没有设置器，它将尝试通过直接设置字段来强制破解模拟，并强制沿途对其进行访问

最重要的是， @InjectMocks静默@InjectMocks失败，因此您可能会在不知道的情况下进行神秘的测试失败。

更重要的是，有些人在Mockito Runner顶部的测试中使用MockitoAnnotations.initMocks()调用，这会导致各种奇怪的事情！！！ 认真的家伙，永远不要打电话。

得到教训

嗯...对不起，吉姆！

@InjectMocks批注的确会尽其所能来做最有用的事情，但是场景越复杂，预测就越困难。

在我看来，使用两种横切技术来初始化对象是一种危险且难以理解的方法，但是，只要有记录，如果可行，则它可能比其他方法更好。 添加评论！

也许需要某种@InjectWithFactory ，您可以在其中声明一个接收所需@InjectWithFactory的方法，并在构造时使用@Mock对象调用该方法，以便您填充其余测试上下文中的任何其他参数。

或者，也许我们只是习惯了这项工作，而忘记了它是否易于理解。

最终思想

我通过创建测试并调试Mockito库以发现它如何实现结果，来了解Mockito在上面的工作。 我强烈建议您以这种方式浏览您最常用的库。 您将学到一些有用的东西！

翻译自: https://www.javacodegeeks.com/2019/11/a-surprising-injection.html