春季测试上下文最佳实践 [英] Spring test context best practice

问题描述

我正在尝试通过集成测试涵盖一个庞大的Spring Boot应用程序.应用程序中有很多Spring bean.加载Spring上下文需要一段时间.

I'm trying to cover a huge Spring Boot application with integration tests. There are lots of Spring beans within the app. It takes a while to load the Spring context.

所以我想知道-

• Spring是否足够聪明，可以在位于不同类中的多个集成测试之间共享相同的上下文?我的意思是避免为每个测试类初始化繁重的上下文.
• 当测试1,2,4使用TestContextOne而测试3,5使用TestContextTwo时会发生什么? Spring是否以1,2,4,3,5顺序启动它们?还是Spring会在内存中保留两个上下文?

• Is Spring clever enough to share the same context between multiple integration tests located in different classes? I mean to avoid initializing the heavy-weight context for each test class.
• What happens when tests 1,2,4 use TestContextOne and tests 3,5 use TestContextTwo? Does Spring launch them in 1,2,4,3,5 order? Or does Spring keep two contexts in memory?

PS 换句话说，是对所有集成测试使用单个完整" Spring Context的惯例，而不是为每个集成测试编写单独的测试?

推荐答案

spring框架提供的用于测试应用程序的主要功能之一是上下文缓存机制，它可以避免您所说的负载开销.春天的文档说:

One of the main features provided by spring framework for testing an application is the context caching mechanism to avoid exactly what you mention about the load overhead. The spring documentation says that:

一旦TestContext框架为测试加载了ApplicationContext(或WebApplicationContext)，该上下文将被缓存并重新用于在同一测试套件中声明相同唯一上下文配置的所有后续测试.

Once the TestContext framework loads an ApplicationContext (or WebApplicationContext) for a test, that context will be cached and reused for all subsequent tests that declare the same unique context configuration within the same test suite.

记住这一点，您必须了解缓存机制如何工作，以确定构建测试的最佳策略.这里的问题是:When spring caches the context, it stores this context in memory using what key?.根据文档，密钥基于容器的某些参数:

With this affirmation in mind you have to understand how the cache mechanism works to determine the best strategy on build your tests. The question here is: When spring caches the context, it stores this context in memory using what key?. According to documentation, the key is based on some parameters of the container:

ApplicationContext可以通过用于加载它的配置参数的组合来唯一标识.因此，配置参数的唯一组合用于生成key，在该key下缓存上下文. TestContext框架使用以下配置参数来构建上下文缓存键:

An ApplicationContext can be uniquely identified by the combination of configuration parameters that are used to load it. Consequently, the unique combination of configuration parameters are used to generate a key under which the context is cached. The TestContext framework uses the following configuration parameters to build the context cache key:

locations(来自@ContextConfiguration)
classes(来自@ContextConfiguration)
contextInitializerClasses(来自@ContextConfiguration)
contextCustomizers(来自ContextCustomizerFactory)
contextLoader(来自@ContextConfiguration)
parent(来自@ContextHierarchy)
activeProfiles(来自@ActiveProfiles)
propertySourceLocations(来自@TestPropertySource)
propertySourceProperties(来自@TestPropertySource)
resourceBasePath(来自@WebAppConfiguration)

locations (from @ContextConfiguration)
classes (from @ContextConfiguration)
contextInitializerClasses (from @ContextConfiguration)
contextCustomizers (from ContextCustomizerFactory)
contextLoader (from @ContextConfiguration)
parent (from @ContextHierarchy)
activeProfiles (from @ActiveProfiles)
propertySourceLocations (from @TestPropertySource)
propertySourceProperties (from @TestPropertySource)
resourceBasePath (from @WebAppConfiguration)

基于此信息，我可能建议您最佳实践是组织测试，使它们使用相同的上下文参数集(即，相同的缓存键)来受益于缓存机制并避免使用其他上下文来被加载. Spring文档也给出了一个示例:

Based on this information I may suggest you that the best practice is organize your tests in a way that they use the same set of context parameters (that is, the same cache key) to benefit from cache mechanism and avoid another context to be loaded. Spring documentation also gives an example:

...，如果TestClassA为@ContextConfiguration的location(或值)属性指定{"app-config.xml", "test-config.xml"}，则TestContext框架将加载相应的ApplicationContext并将其存储在键下的静态上下文缓存中仅基于这些位置.因此，如果TestClassB还为其位置(通过继承显式或隐式)定义了{"app-config.xml", "test-config.xml"}，但未定义@WebAppConfiguration，则另外一个ContextLoader，不同的活动配置文件，不同的上下文初始化程序，不同的测试属性源或在不同的父上下文中，然后两个测试类将共享相同的ApplicationContext .这意味着(每个测试套件)仅需加载一次加载应用程序上下文的设置成本，并且后续测试的执行速度要快得多.

..., if TestClassA specifies {"app-config.xml", "test-config.xml"} for the locations (or value) attribute of @ContextConfiguration, the TestContext framework will load the corresponding ApplicationContext and store it in a static context cache under a key that is based solely on those locations. So if TestClassB also defines {"app-config.xml", "test-config.xml"} for its locations (either explicitly or implicitly through inheritance) but does not define @WebAppConfiguration, a different ContextLoader, different active profiles, different context initializers, different test property sources, or a different parent context, then the same ApplicationContext will be shared by both test classes. This means that the setup cost for loading an application context is incurred only once (per test suite), and subsequent test execution is much faster.

这篇关于春季测试上下文最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！