11

嗨，我不明白使用 @ContextHierarchy 有什么好处，如下所示：

@ContextHierarchy({
  @ContextConfiguration("/test-db-setup-context.xml"),
  @ContextConfiguration("FirstTest-context.xml")
})
@RunWith(SpringJUnit4ClassRunner.class)
public class FirstTest {
 ...
}

@ContextHierarchy({
  @ContextConfiguration("/test-db-setup-context.xml"),
  @ContextConfiguration("SecondTest-context.xml")
})
@RunWith(SpringJUnit4ClassRunner.class)
public class SecondTest {
 ...
}

过度使用带有位置参数的单个 @ContextConfiguration，如下所示：

@ContextConfiguration(locations = {"classpath:test-db-setup-context.xml", "FirstTest-context.xml", "SecondTest-context.xml" })

在每种情况下，应用程序上下文在不同的 junit 测试类之间共享。

4

2 回答 2

2

不同之处在于上下文层次结构中每个上下文中的 bean 无法看到上下文中的其他 bean。因此，您可以隔离被测物品的不同部分。

于 2017-06-14T10:21:37.727 回答
0

这里要注意的重要一点是，如果@ContextHierarchy我们得到具有单独生命周期（初始化、关闭）的单独上下文。这很重要，因为例如它们可以独立失败。

我院子里的一个实际例子。我们有一个与一些外部服务通信的 Spring 应用程序。我们想要一个启动这些依赖服务并运行测试的 E2E 测试。所以我们在我们的 : 中添加了一个初始化器@ContextConfiguration：

@ContextConfiguration{classes = TheApp.class, initializers = DockerInitializer.class}
public class TheAppE2ETests {
    // ...
}

初始化程序正在准备外部服务（启动 Docker），自定义属性以便应用程序可以运行并附加到关闭上下文事件，以便清理 Docker。当应用程序上下文无法加载时（例如由于错误），这种方法会出现问题：

  1. 初始化失败后，ContextClosedEvent不会触发 - 码头工人没有停止和清理。
  2. 当上下文加载失败时，初始化程序会为每个运行的测试一遍又一遍地调用（不仅是每个测试类 - 每个测试方法！）。

因此，每次应用程序上下文中的错误导致初始化失败时，测试都会继续杀死我们的 CI 环境。为每个单独的测试方法启动了依赖服务的容器，然后没有清理。

我们最终@ContextConfiguration为 docker 和应用程序本身使用并拥有两个独立的上下文。这样，在上述情况下，dockers 会在单独的上下文中启动，因此可以在其中生活，甚至可以在多个 Spring 测试之间共享（由于 Spring 的上下文缓存机制）。

于 2019-02-15T12:23:01.903 回答