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

Question

我最近在我目前的项目中担任自由职业者.我投入的一件事就是失败的詹金斯建筑(从4月8日开始失败,在我开始前一周).

一般来说,您可以在日志中看到一系列DI问题.我做的第一件事就是从相同的应用程序上下文开始,以相同的方式使所有测试工作.他们还实施了自己的"嘲弄"的东西,似乎无法正常工作.在与开发者讨论后,我建议开始使用Springockito.(对于某个模块,他们需要模拟他们的集成测试 - 遗留原因,无法更改)

无论如何,事情之后开始失败了.在测试中被嘲笑的很多豆子都没有被嘲笑,或者没有找到或者其他什么.通常,它会在加载应用程序上下文时失败,说明缺少一个或另一个bean.

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

这个故事的一个侧面是他们已经升级到Hibernate 4,因此升级到Spring 3.2.以前,他们使用的是旧版本的Spring 3.当时所有测试都在进行,并且没有必要使用@DirtiesContext.

现在,让我最担心的是,我无法立即想到对这种奇怪行为的解释.通过启动使用@Autowired bean的测试,几乎可以看出Springs上下文变脏了.并非所有测试都使用Mocks,因此不可能.这听起来对任何人都很熟悉吗？有没有人与Spring(最新版本)Spring的集成测试有相同的经验？

在Stackoverflow上,我找到了这张票:如何测试'脏'弹簧应用程序上下文？ 它似乎几乎总结了我所看到的行为,但关键是我们是自动装配服务/存储库/ ......,而且我们在这些类上没有任何设置器.

有什么想法吗？

谢谢!

Answer 1

回答我自己的问题，秘密就在 Spring 版本中。我们使用的是 Spring 3.1.3，而我推测他们使用的是 Spring 3.2（他们不断谈论 Spring 版本的最新升级）。

解释就在这里，我在寻找修复它的过程中偶然发现了一篇博客文章：Spring Framework 3.2 RC1：新测试功能

以及相关部分的复制粘贴：

Spring 配置中通用工厂方法的使用绝不是特定于测试的，但是通用工厂方法（例如 EasyMock.createMock(MyService.class) 或 Mockito.mock(MyService.class)）通常用于为 Spring bean 创建动态模拟在测试应用程序上下文中。例如，在 Spring Framework 3.2 之前，以下配置可能无法将 OrderRepository 自动装配到 OrderService 中。原因是，根据 bean 在应用程序上下文中初始化的顺序，Spring 可能会将 orderRepository bean 的类型推断为 java.lang.Object，而不是 com.example.repository.OrderRepository。

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

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

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

使用这个策略，我再次构建并运行，并且所有测试都运行正常。它并不完美，但它正在工作，而且是一致的。