与纯@ContextConfiguration相比，使用@ContextHierarchy有什么好处

Question

嗨，我不明白有什么优点可以让我使用@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 {
 ...
}

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

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

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

Answer 1

区别在于上下文层次结构中每个上下文中的bean都无法在另一个上下文中看到bean。因此，您可以隔离测试项目的不同部分。

Answer 2

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

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

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

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

1. 初始化失败后，ContextClosedEvent没有被解雇 - 码头工人没有停下来并被清理干净。
2. 当上下文无法加载时，对于每个运行的测试都会反复调用初始化程序（不仅是每个测试类 - 对于每个测试方法！）。

因此，每次App应用程序上下文中的错误导致初始化失败时，测试都会一直在杀死我们的CI环境。依赖服务的容器是针对每种测试方法启动的，然后不进行清理。

我们最终使用@ContextConfiguration并为dockers和The App本身提供了两个独立的上下文。这种方式在上述情况下，docker在一个单独的上下文中启动，因此可以在那里生活，甚至可以在多个Spring测试中共享（由于Spring的上下文缓存机制）。