java - 每次集成测试后 Spring 上下文变脏

Question

我最近以自由职业者的身份开始了我当前的项目。我投入其中的一件事是失败的 Jenkins 构建(它从 4 月 8 日开始失败，也就是我开始这里的前一周)。

一般来说，您可以在日志中看到一大堆 DI 问题。我做的第一件事是让所有测试以相同的方式工作，从相同的应用程序上下文开始。他们还实现了自己的“模拟”东西，但似乎无法正常工作。在与主要开发人员讨论后，我建议开始使用 Springockito。 (对于某个模块，他们需要模拟他们的集成测试 - 遗留原因，无法更改)

无论如何，在那之后事情开始严重失败。许多在测试中被模拟的 bean，根本就没有被模拟，或者没有被发现等等。通常，它会在加载应用程序上下文时失败，表明缺少一个或另一个 bean。

我尝试了不同的东西和不同的方法，但最后，只有我最担心的方法会起作用:将@DirtiesContext 添加到每个测试中。现在，maven 构建又开始变绿了，测试开始做他们应该做的事情。但是我每次都重新加载 Spring 上下文，这需要时间 - 这是相对的，因为上下文在大约 1 - 2 秒内加载。

这个故事的旁注是他们已经升级到 Hibernate 4，从而升级到 Spring 3.2。以前，他们使用的是旧版本的 Spring 3。当时所有测试都正常，@DirtiesContext 不是必需的。

现在，最让我担心的是，我无法立即想到对这种奇怪行为的解释。似乎 Springs 上下文很脏，只需启动一个使用 @Autowired bean 的测试即可。并非所有测试都使用 Mocks，所以不可能。这听起来很熟悉吗？有没有人对使用(最新版本的)Spring 进行集成测试有相同的经验？

在 Stackoverflow 上，我找到了这张票:How can a test 'dirty' a spring application context?它似乎几乎总结了我所看到的行为，但关键是我们正在 Autowiring 服务/存储库/......，并且我们在这些类上没有任何 setter 。

有什么想法吗？

谢谢!

Answer 1

要回答我自己的问题， secret 就在 Spring 版本中。我们使用的是 Spring 3.1.3，而我认为他们使用的是 Spring 3.2(他们一直在谈论 Spring 版本的最新升级)。

解释在这里，我在寻找修复它的过程中偶然发现了一篇博客文章:Spring Framework 3.2 RC1: New Testing Features

以及相关作品的复制粘贴:

The use of generic factory methods in Spring configuration is by no means specific to testing, but generic factory methods such as EasyMock.createMock(MyService.class) or Mockito.mock(MyService.class) are often used to create dynamic mocks for Spring beans in a test application context. For example, prior to Spring Framework 3.2 the following configuration could fail to autowire the OrderRepository into the OrderService. The reason is that, depending on the order in which beans are initialized in the application context, Spring would potentially infer the type of the orderRepository bean to be java.lang.Object instead of com.example.repository.OrderRepository.

那么，我是如何解决这个问题的呢？好吧，我做了以下步骤:

• 创建一个新的maven模块
• 过滤掉需要模拟的测试。所有非模拟测试都将在 Spring 构建中正常运行，在单独的 Failsafe 运行中(我创建了一个“干净”的基本包，并像那样将它们分类)
• 将所有模拟测试放入名为“mocked”的基础包中，并在 Failsafe 中为模拟测试额外运行一次。
• 每个模拟测试都使用 Springockito 创建模拟。我还使用 Springockito 注释来轻松地执行 @ReplaceWithMock。然后每个模拟测试都用@DirtiesContext 注释，因此上下文在每次测试后都会变脏，并且每次测试都会重新引入 Spring 上下文。

我能给出的唯一合理解释是上下文实际上被弄脏了，因为有一个框架 (Springockito) 从 Spring 框架接管了 Spring bean 的管理。我不知道这是否正确，但这是我能想到的最好的解释。事实上，这就是脏上下文的定义，这就是我们需要将其标记为脏的原因。

使用这个策略，我再次构建并运行，所有测试都运行正常。它并不完美，但很有效，而且始终如一。