Testing

@BootstrapWith是一个类级批注，您可以使用它来配置如何引导Spring TestContext框架。具体地说，您可以使用@BootstRapWith指定一个定制的TestContextBootstRapper。有关更多详细信息，请参阅引导TestContext框架一节。

@ConextConfiguration定义类级别的元数据，用于确定如何为集成测试加载和配置ApplicationContext。具体地说，@ConextConfiguration声明了用于加载上下文的应用程序上下文资源位置或组件类。

资源位置通常是位于类路径中的XML配置文件或Groovy脚本，而组件类通常是@configuration类。但是，资源位置也可以引用文件系统中的文件和脚本，组件类可以是@Component类、@Service类等。有关详细信息，请参阅组件类。

下面的示例显示了引用XML文件的@ConextConfiguration批注：

下面的示例显示了引用类的@ConextConfiguration批注：

作为替代方法或除了声明资源位置或组件类之外，您还可以使用@ContextConfiguration声明ApplicationContextInitializer类。以下示例显示了这样的情况：

您也可以选择使用@ConextConfiguration来声明ConextLoader策略。但是请注意，您通常不需要显式配置加载器，因为默认加载器支持初始值设定项和资源位置或组件类。

以下示例同时使用位置和加载器：

有关更多详细信息，请参阅上下文管理、@nesteed测试类配置和@ConextConfigurationjavados。

@WebAppConfiguration是一个类级批注，可用于声明为集成测试加载的ApplicationContext应为WebApplicationContext。仅在测试类上存在@WebAppConfiguration就可以确保为测试加载WebApplicationContext，并使用指向Web应用程序根的路径(即资源库路径)的默认值“file：src/main/webapp”。资源基本路径在后台用于创建MockServletContext，它用作测试的WebApplicationContext的ServletContext。

以下示例显示如何使用@WebAppConfiguration批注：

要覆盖缺省值，可以使用隐式值属性指定不同的基本资源路径。同时支持classpath：和file：资源前缀。如果未提供资源前缀，则假定该路径为文件系统资源。以下示例显示如何指定类路径资源：

请注意，@WebAppConfiguration必须与@ConextConfiguration一起使用，无论是在单个测试类中还是在测试类层次结构中。有关更多详细信息，请参阅@WebAppConfigurationjavadoc。

@ContextHierarchy是一个类级批注，用于定义集成测试的ApplicationContext实例的层次结构。@ConextHierarchy应该用一个或多个@ConextConfiguration实例的列表声明，每个实例都定义了上下文层次结构中的一个级别。以下示例演示了@ConextHierarchy在单个测试类中的使用(@ConextHierarchy也可以在测试类层次结构中使用)：

如果您需要合并或覆盖测试类层次结构中给定的上下文层次结构级别的配置，则必须通过向类层次结构中每个相应级别的@ConextConfiguration中的name属性提供相同的值来显式命名该级别。有关更多示例，请参阅上下文层次结构和@ConextHierarchyjavadoc。

@ActiveProfiles是一个类级批注，用于声明在为集成测试加载ApplicationContext时，哪些Bean定义概要文件应该是活动的。

以下示例指示dev配置文件应处于活动状态：

以下示例指示dev和集成配置文件都应处于活动状态：

有关示例和更多详细信息，请参阅环境概要文件的上下文配置、@nesteed测试类配置和@ActiveProfilesjavadoc。

@TestPropertySource是一个类级批注，您可以使用它来配置属性文件和内联属性的位置，这些属性文件和内联属性将添加到Environment中为集成测试加载的ApplicationContext的PropertySources集中。

下面的示例演示如何从类路径声明属性文件：

下面的示例演示如何声明内联属性：

有关示例和更多详细信息，请参阅使用测试属性源的上下文配置。

@DynamicPropertySource是方法级批注，可用于注册动态属性以添加到Environment中为集成测试加载的ApplicationContext的PropertySources集中。当您事先不知道属性的值时，动态属性非常有用-例如，如果属性由外部资源管理，例如由Testtainers项目管理的容器。

下面的示例演示如何注册动态属性：

有关详细信息，请参阅动态属性源上下文配置。

@DirtiesContext表示底层的SpringApplicationContext在测试执行期间已被破坏(即，测试以某种方式 - 修改或损坏了它，例如，通过更改Singleton Bean的状态)，应该关闭。当应用程序上下文被标记为脏时，它将从测试框架的缓存中移除并关闭。因此，对于需要具有相同配置元数据的上下文的任何后续测试，都会重新构建底层的Spring容器。

您可以将@DirtiesContext用作同一个类或类层次结构中的类级和方法级批注。在这种情况下，ApplicationContext在任何此类带注释的方法之前或之后以及当前测试类之前或之后被标记为脏，这取决于配置的方法模式和类模式。

以下示例说明了在各种配置场景中，环境何时会被破坏：

如果您在测试中使用@DirtiesContext，而该测试的上下文被配置为使用@ConextHierarchy的上下文层次结构的一部分，则可以使用HierarchyMode标志来控制如何清除上下文缓存。默认情况下，使用穷举算法来清除上下文缓存，不仅包括当前级别，还包括共享当前测试共有的祖先上下文的所有其他上下文层次结构。驻留在公共祖先上下文子层次结构中的所有ApplicationContext实例都从上下文缓存中移除并关闭。如果穷举算法对于特定用例来说过于苛刻，您可以指定更简单的Current Level算法，如下例所示。

有关<代码>穷举 和<代码>CURRENT_LEVEL 算法的更多详细信息，请参阅DirtiesContext.HierarchyModejavadoc。

@TestExecutionListeners用于注册特定测试类、其子类及其嵌套类的侦听器。如果您希望全局注册侦听器，则应该通过TestExecutionListener配置中描述的自动发现机制进行注册。

以下示例显示如何注册两个TestExecutionListener实现：

默认情况下，@TestExecutionListeners支持从超类或封闭类继承侦听器。有关示例和更多详细信息，请参阅@nested测试类配置和@TestExecutionListenersjavadoc。如果您发现需要切换回使用默认的TestExecutionListener实现，请参阅注册TestExecutionListener实现中的说明。

@RecordApplicationEvents是一个类级别的批注，用于指示Spring TestContext框架记录单个测试执行期间在ApplicationContext中发布的所有应用程序事件。

可以通过测试内部的ApplicationEvents接口访问录制的事件。

有关示例和更多详细信息，请参阅应用程序事件和@RecordApplicationEventsjavadoc。

@Commit表示事务性测试方法的事务应该在测试方法完成后提交。您可以使用@Commit作为@Rollback(FALSE)的直接替代，以更明确地传达代码的意图。与@Rollback类似，@Commit也可以声明为类级别或方法级别的批注。

下面的示例显示如何使用@Commit批注：

@Rollback事务性测试方法的事务是否应该在测试方法完成后回滚。如果为True，则回滚事务。否则，事务被提交(另请参见@Commit)。在Spring TestContext框架中，集成测试的回滚默认为true，即使没有显式声明@Rollback。

当声明为类级注释时，@Rollback为测试类层次结构中的所有测试方法定义了默认的回滚语义。当声明为方法级批注时，@Rollback定义特定测试方法的回滚语义，可能会覆盖类级@Rollback或@Commit语义。

下面的示例导致测试方法的结果不会回滚(即，结果提交到数据库)：

@BeForeTransaction表示，对于已使用Spring的@Transaction注释配置为在事务内运行的测试方法，应在启动事务之前运行带注释的void方法。@BeForeTransaction方法不要求为公共，可以在基于Java 8的接口默认方法上声明。

下面的示例显示如何使用@BeForeTransaction批注：

@AfterTransaction表示，对于已使用Spring的@Transaction注释配置为在事务内运行的测试方法，应在事务结束后运行带注释的void方法。@AfterTransaction方法不要求为公共，可以在基于Java 8的接口默认方法上声明。

@SQL用于注释测试类或测试方法，以配置在集成测试期间针对给定数据库运行的SQL脚本。以下示例显示如何使用它：

有关详细信息，请参阅使用@SQL以声明方式执行SQL脚本。

@SqlConfig定义用于确定如何解析和运行使用@SQL注释配置的SQL脚本的元数据。以下示例显示如何使用它：

@SqlMergeMode用于标注测试类或测试方法，配置方法级@SQL声明是否与类级@SQL声明合并。如果测试类或测试方法上未声明@SqlMergeMode，则默认情况下将使用覆盖合并模式。使用覆盖模式，方法级@SQL声明将有效地覆盖类级@SQL声明。

请注意，方法级@SqlMergeModel声明覆盖类级声明。

下面的示例展示了如何在类级别使用@SqlMergeMode。

以下示例说明如何在方法级别使用@SqlMergeMode。

@SqlGroup是一个容器批注，聚合了几个@SQL批注。您可以在本地使用@SqlGroup声明几个嵌套的@SQL批注，也可以将其与Java 8对可重复批注的支持结合使用，其中@SQL可以在同一个类或方法上声明多次，从而隐式生成该容器批注。以下示例显示如何声明一个SQL组：

@IfProfileValue表示为特定测试环境启用了带注释的测试。如果配置的ProfileValueSource为提供的名称返回匹配的值，则启用测试。否则，该测试将被禁用并实际上被忽略。

您可以在类级别、方法级别或两者都应用@IfProfileValue。对于该类或其子类中的任何方法，类级别的使用@IfProfileValue优先于方法级别的使用。具体地说，如果在类级别和方法级别都启用了测试，则启用该测试。@IfProfileValue的缺失意味着测试是隐式启用的。这类似于JUnit4的@Ignore注释的语义，不同之处在于@Ignore的存在总是禁用测试。

下面的示例显示具有@IfProfileValue批注的测试：

或者，您可以使用值列表(使用OR语义)配置@IfProfileValue，以在JUnit4环境中实现对测试组的类似于TestNG的支持。请考虑以下示例：

@ProfileValueSourceConfiguration是一个类级批注，它指定在检索通过@IfProfileValue批注配置的配置文件值时使用哪种类型的ProfileValueSource。如果没有为测试声明@ProfileValueSourceConfiguration，则默认使用SystemProfileValueSource。以下示例说明如何使用@ProfileValueSourceConfiguration：

@Timed表示带注释的测试方法必须在指定的时间段(以毫秒为单位)内完成执行。如果文本执行时间超过指定的时间段，则测试失败。

时间段包括运行测试方法本身、测试的任何重复(参见@Repeat)以及测试夹具的任何设置或拆除。以下示例显示如何使用它：

Spring的@Timed注释的语义与JUnit4的@Test(TimeOut=…)不同​)支持。具体地说，由于JUnit4处理测试执行超时的方式(即通过在单独的<代码>线程 中执行测试方法)，<代码>@测试(TimeOut=…​)如果测试花费的时间太长，则会抢先使测试失败。另一方面，Spring的@timed不会抢先通过测试，而是等待测试完成后才会失败。

@Repeat表示带注释的测试方法必须重复运行。测试方法要运行的次数在注释中指定。

重复执行的范围包括测试方法本身的执行以及测试夹具的任何设置或拆除。当与SpringMethodRule一起使用时，作用域还包括通过TestExecutionListener实现准备测试实例。下面的示例显示如何使用@Repeat批注：

@SpringJUnitConfig是一个组合批注，它将来自JUnitJupiter的@ExtendWith(SpringExtension.class)与来自Spring TestContext框架的@ConextConfiguration组合在一起。它可以在类级别用作@ConextConfiguration的临时替代。关于配置选项，@ConextConfiguration和@SpringJUnitConfig的唯一区别是组件类可以在@SpringJUnitConfig中用值属性声明。

以下示例显示如何使用@SpringJUnitConfig批注指定配置类：

下面的示例显示如何使用@SpringJUnitConfig批注指定配置文件的位置：

有关详细信息，请参阅上下文管理以及@SpringJUnitConfig和@ConextConfiguration的javadoc。

@SpringJUnitWebConfig是一个组合批注，它将来自JUnitJupiter的@ExtendWith(SpringExtension.class)与来自Spring TestContext框架的@ConextConfiguration和@WebAppConfiguration组合在一起。您可以在类级别使用它作为@ConextConfiguration和@WebAppConfiguration的临时替代。关于配置选项，@ConextConfiguration和@SpringJUnitWebConfig的唯一区别是可以通过@SpringJUnitWebConfig中的值属性声明组件类。此外，您只能通过使用@SpringJUnitWebConfig中的resource cePath属性来覆盖@WebAppConfiguration中的值属性。

以下示例显示如何使用@SpringJUnitWebConfig批注指定配置类：

下面的示例显示如何使用@SpringJUnitWebConfig批注指定配置文件的位置：

有关更多详细信息，请参阅上下文管理以及@SpringJUnitWebConfig，@ContextConfiguration，和@WebAppConfiguration的javadoc。

@TestConstructor是一个类型级注释，用于配置如何从测试的ApplicationContext中的组件自动连接测试类构造函数的参数。

如果测试类上不存在@TestConstructor或元存在，则将使用默认的测试构造函数自动布线模式。有关如何更改默认模式的详细信息，请参阅下面的提示。然而，请注意，构造函数上的@AuTower的本地声明优先于@TestConstructor和默认模式。

@NestedTestConfiguration是一个类型级批注，用于配置如何在内部测试类的封闭类层次结构中处理Spring测试配置批注。

如果测试类、其超类型层次结构或其封闭类层次结构中不存在@NestedTestConfiguration或元存在，则将使用默认的封闭配置继承模式。有关如何更改默认模式的详细信息，请参阅下面的提示。

Spring TestContext框架遵循以下批注的@NestedTestConfiguration语义。

有关示例和更多详细信息，请参阅@nesteed测试类配置。

@EnabledIf用于表示带注释的JUnit Jupiter测试类或测试方法已启用，如果提供的表达式的计算结果为true，则应运行该测试类或测试方法。具体地说，如果表达式的计算结果为Boolan.TRUE或字符串等于true(忽略大小写)，则启用测试。当应用于类级别时，该类中的所有测试方法在默认情况下也会自动启用。

表达式可以是以下任意一种：

然而，请注意，不是属性占位符动态解析结果的文本文本没有实际价值，因为@EnabledIf(“False”)等同于@Disable和@EnabledIf(“true”)在逻辑上没有意义。

您可以使用@EnabledIf作为元批注来创建自定义合成批注。例如，您可以创建一个自定义@EnabledOnMac批注，如下所示：

@DisabledIf用于通知带注释的JUnit Jupiter测试类或测试方法被禁用，如果提供的表达式的计算结果为true，则不应运行该测试类或测试方法。具体地说，如果表达式的计算结果为Boolan.TRUE或字符串等于true(忽略大小写)，则测试将被禁用。在类级别应用时，该类中的所有测试方法也会自动禁用。

表达式可以是以下任意一种：

然而，请注意，不是属性占位符动态解析结果的文本文字没有实际价值，因为@DisabledIf(“true”)等同于@DisabledIf(“False”)和@DisabledIf(“False”)在逻辑上没有意义。

您可以使用@DisabledIf作为元批注来创建自定义合成批注。例如，您可以创建一个自定义@DisabledOnMac批注，如下所示：

TestContext封装运行测试的上下文(与实际使用的测试框架无关)，并为它负责的测试实例提供上下文管理和缓存支持。TestContext还委托SmartConextLoader在请求时加载ApplicationContext。

TestConextManager是进入Spring TestContext框架的主要入口点，负责管理单个TestContext，并在定义良好的测试执行点向每个注册的TestExecutionListener发送事件：

TestExecutionListener定义用于响应监听器注册到的TestConextManager发布的测试执行事件的API。参见TestExecutionListener配置。

ConextLoader是一个策略接口，用于为Spring TestContext框架管理的集成测试加载ApplicationContext。您应该实现SmartConextLoader而不是此接口，以提供对组件类、活动Bean定义配置文件、测试属性源、上下文层次结构和WebApplicationContext支持的支持。

SmartConextLoader是ConextLoader接口的扩展，它取代了原始的最小ConextLoaderSPI。具体地说，SmartConextLoader可以选择处理资源位置、组件类或上下文初始值设定项。此外，SmartConextLoader可以设置活动的Bean定义配置文件，并在它加载的上下文中测试属性源。

Spring提供了以下实现：

您可以使用@TestExecutionListeners注释为测试类、其子类及其嵌套类显式注册TestExecutionListener实现。有关详细信息和示例，请参阅批注支持和@TestExecutionListeners的javadoc。

使用@TestExecutionListeners注册TestExecutionListener实现适用于有限测试场景中使用的自定义监听器。但是，如果需要在整个测试套件中使用自定义侦听器，则可能会变得很麻烦。这个问题通过支持通过SpringFactoriesLoader机制自动发现默认的TestExecutionListener实现来解决。

具体地说，Spring-test模块在其META-INF/spring.Factory属性文件中的org.springframework.test.context.TestExecutionListener注册表项下声明了所有核心默认TestExecutionListener实现。第三方框架和开发人员可以通过自己的META-INF/spring.Factory属性文件，以相同的方式将自己的TestExecutionListener实现贡献给默认侦听器列表。

当TestContext框架通过上述SpringFactoriesLoader机制发现默认的TestExecutionListener实现时，实例化的侦听器将使用Spring的AnnotationAwareOrderCompator进行排序，它遵循Spring的Order接口和@Order注释。AbstractTestExecutionListener和所有由Spring提供的默认TestExecutionListener实现使用适当的值实现有序的。因此，第三方框架和开发人员应该确保他们的默认TestExecutionListener实现以正确的顺序注册，方法是实现ordered或声明@order。有关为每个核心侦听器分配什么值的详细信息，请参阅核心默认TestExecutionListener实现的getOrder()方法的javadoc。

如果自定义TestExecutionListener是通过@TestExecutionListeners注册的，则不会注册默认监听器。在大多数常见的测试场景中，这实际上会迫使开发人员手动声明除任何自定义侦听器之外的所有默认侦听器。下面的清单演示了这种配置风格：

这种方法的挑战在于，它要求开发人员准确地知道默认情况下注册了哪些监听器。此外，默认侦听器的集合可以在不同的版本中更改。例如，<DirtiesContextBeforeModesTestExecutionListener> >SqlScriptsTestExecutionListener 是在Spring Framework4.1中引入的，而SqlScriptsTestExecutionListener是在Spring Framework4.2中引入的。此外，像Spring Boot和Spring Security这样的第三方框架通过使用前面提到的自动发现机制来注册它们自己的默认TestExecutionListener实现。

为了避免知道并重新声明所有默认侦听器，您可以将@TestExecutionListeners的mergeMode属性设置为MergeMode.MERGE_WITH_DEFAULTS。MERGE_WITH_DEFAULTS表示本地声明的监听程序应该与默认监听程序合并。合并算法确保从列表中删除重复项，并根据AnnotationAwareOrderCompator的语义对合并后的侦听器的结果集进行排序，如排序TestExecutionListener实现中所述。如果侦听器实现Order或使用@Order注释，它可能会影响它与默认值合并的位置。否则，本地声明的侦听器将在合并时附加到默认侦听器列表中。

例如，如果上例中的MyCustomTestExecutionListener类将其order值(例如，500)配置为小于ServletTestExecutionListener(恰好是1000)的顺序，则MyCustomTestExecutionListener可以自动与ServletTestExecutionListener前面的默认列表合并，并且前面的示例可以替换为以下内容：

默认情况下，如果测试执行事件侦听器在使用事件时抛出异常，则该异常将传播到正在使用的底层测试框架(如JUnit或TestNG)。例如，如果消费BeForeTestMethodEvent导致异常，则相应的测试方法将因该异常而失败。相反，如果异步测试执行事件侦听器引发异常，则该异常不会传播到基础测试框架。有关异步异常处理的更多详细信息，请参考@EventListener的类级javadoc。

如果您希望特定的测试执行事件侦听器异步处理事件，您可以使用Spring的常规@async支持。有关更多详细信息，请参考@EventListener的类级javadoc。

要使用XML配置文件为您的测试加载ApplicationContext，请使用@ConextConfiguration注释您的测试类，并使用包含XML配置元数据的资源位置的数组配置Locations属性。普通路径或相对路径(例如，context.xml)被视为相对于定义测试类的包的类路径资源。以斜杠开头的路径被视为绝对类路径位置(例如，/org/Example/config.xml)。表示资源URL的路径(即以classpath：、file：、http：等为前缀的路径)按原样使用。

@ConextConfiguration通过标准的Java值属性支持Locations属性的别名。因此，如果您不需要在@ConextConfiguration中声明其他属性，则可以省略Locations属性名称的声明，并使用以下示例中演示的速记格式声明资源位置：

如果在@ConextConfiguration注释中同时省略了位置和值属性，则TestContext框架会尝试检测默认的XML资源位置。具体地说，GenericXmlContextLoader和GenericXmlWebConextLoader根据测试类的名称检测默认位置。如果您的类名为com.example.MyTest，GenericXmlConextLoader从“classpath:com/example/MyTest-context.xml”.加载您的应用程序上下文以下示例显示了如何执行此操作：

要通过使用使用Groovy Bean定义DSL的Groovy脚本为您的测试加载ApplicationContext，您可以使用@ConextConfiguration注释您的测试类，并使用包含Groovy脚本资源位置的数组配置位置或值属性。Groovy脚本的资源查找语义与XML配置文件中描述的相同。

下面的示例显示如何指定Groovy配置文件：

如果您在@ConextConfiguration注释中同时省略了位置和值属性，那么TestContext框架将尝试检测默认的Groovy脚本。具体地说，GenericGroovyXmlConextLoader和GenericGroovyXmlWebConextLoader根据测试类的名称检测默认位置。如果您的类被命名为com.example.MyTest，则Groovy上下文加载器从“classpath:com/example/MyTestContext.groovy”.加载您的应用程序上下文以下示例显示如何使用默认设置：

要使用组件类为您的测试加载ApplicationContext(请参阅基于Java的容器配置)，您可以使用@ConextConfiguration注释测试类，并使用包含对组件类的引用的数组来配置Class属性。以下示例显示了如何执行此操作：

如果您在@ConextConfiguration注释中省略了CLASS属性，那么TestContext框架会尝试检测默认配置类的存在。具体地说，AnnotationConfigConextLoader和AnnotationConfigWebConextLoader检测满足配置类实现要求的测试类的所有静态类，如@configurationjavadoc中指定的。请注意，配置类的名称是任意的。此外，如果需要，一个测试类可以包含多个静态嵌套配置类。在下面的示例中，OrderServiceTest类声明了一个名为Config的静态嵌套配置类，该类自动用于加载测试类的ApplicationContext：

有时可能需要混合使用XML配置文件、Groovy脚本和组件类(通常是@Configuration类)来为您的测试配置ApplicationContext。例如，如果您在生产中使用XML配置，您可能决定使用@Configuration类为您的测试配置特定的Spring管理的组件，反之亦然。

此外，一些第三方框架(如Spring Boot)为同时从不同类型的资源(例如，XML配置文件、Groovy脚本和@Configuration类)加载ApplicationContext提供了一流的支持。从历史上看，Spring框架不支持标准部署的这一点。因此，Spring框架在Spring-test模块中交付的大多数SmartConextLoader实现对于每个测试上下文只支持一种资源类型。然而，这并不意味着您不能同时使用两者。一般规则的一个例外是GenericGroovyXmlConextLoader和GenericGroovyXmlWebConextLoader同时支持XML配置文件和Groovy脚本。此外，第三方框架可以选择通过@ConextConfiguration同时支持位置和类的声明，并且，借助TestContext框架中的标准测试支持，您可以选择以下选项。

如果您希望使用资源位置(例如，XML或Groovy)和@Configuration类来配置测试，则必须选择其中一个作为入口点，并且必须包含或导入另一个。例如，在XML或Groovy脚本中，您可以通过使用组件扫描或将它们定义为普通的Spring Bean来包括@Configuration类，而在@Configuration类中，您可以使用@ImportResource来导入XML配置文件或Groovy脚本。请注意，此行为在语义上等同于您在生产中配置应用程序的方式：在生产配置中，您定义了一组XML或Groovy资源位置或一组@Configuration类，从中加载您的生产ApplicationContext，但您仍然可以自由地包括或导入其他类型的配置。

若要使用上下文初始值设定项为您的测试配置ApplicationContext，请使用@ConextConfiguration注释您的测试类，并使用包含对实现ApplicationContextInitializer的类的引用的数组来配置Initializers属性。然后使用声明的上下文初始值设定项来初始化为测试加载的ConfigurableApplicationContext。请注意，每个声明的初始值设定项支持的具体ConfigurableApplicationContext类型必须与正在使用的SmartConextLoader创建的ApplicationContext类型兼容(通常是GenericApplicationContext)。此外，调用初始化器的顺序取决于它们是实现了Spring的Order接口，还是使用了Spring的@Order批注或标准的@优先级批注。以下示例显示如何使用初始值设定项：

您还可以完全省略@ConextConfiguration中的XML配置文件、Groovy脚本或组件类的声明，而只声明ApplicationContextInitializer类，这些类然后负责在上下文 - 中注册Bean，例如，通过编程方式从XML文件或配置类加载Bean定义。以下示例显示了如何执行此操作：

@ConextConfiguration支持布尔型inheritLocations和inheritInitializers属性，这些属性指示是否应该继承超类声明的资源位置或组件类和上下文初始值设定项。这两个标志的默认值都是true。这意味着测试类继承任何超类声明的资源位置或组件类以及上下文初始值设定项。具体地说，测试类的资源位置或组件类被附加到超类声明的资源位置或注释类的列表中。类似地，给定测试类的初始化器被添加到由测试超类定义的初始化器集合中。因此，子类可以选择扩展资源位置、组件类或上下文初始值设定项。

如果@ConextConfiguration中的inheritLocations或inheritInitializers属性设置为FALSE，则测试类的资源位置或组件类以及上下文初始值设定项将分别隐藏并有效替换超类定义的配置。

在下一个使用XML资源位置的示例中，ExtendedTest的ApplicationContext是从base-config.xml和Extended-config.xml加载的。因此，Extended-config.xml中定义的Bean可以覆盖(即替换)base-config.xml中定义的Bean。下面的示例显示一个类如何扩展另一个类并同时使用其自己的配置文件和超类的配置文件：

类似地，在下一个使用组件类的示例中，ExtendedTest的ApplicationContext是从BaseConfig和ExtendedConfig类加载的。因此，ExtendedConfig中定义的Bean可以重写(即替换)BaseConfig中定义的Bean。下面的示例显示一个类如何扩展另一个类并同时使用其自己的配置类和超类的配置类：

在下一个使用上下文初始化器的示例中，使用BaseInitializer和ExtendedInitializer初始化ExtendedTest的ApplicationContext。但是请注意，调用初始化器的顺序取决于它们是实现了Spring的Order接口，还是使用了Spring的@Order批注或标准的@优先级批注。下面的示例说明一个类如何扩展另一个类并同时使用其自己的初始值设定项和超类的初始值设定项：

Spring框架对环境和概要文件的概念提供了一流的支持(也称为“Bean定义概要文件”)，并且可以配置集成测试来为各种测试场景激活特定的Bean定义概要文件。这是通过使用@ActiveProfiles注释来注释测试类，并提供在为测试加载ApplicationContext时应该激活的配置文件列表来实现的。

考虑两个具有XML配置和@Configuration类的示例：

当TransferServiceTest运行时，其ApplicationContext将从类路径根目录下的app-config.xml配置文件中加载。如果您检查app-config.xml，您可以看到bactRepositoryBean依赖于DataSourceBean。但是，DataSource未定义为顶级Bean。相反，DataSource定义了三次：生产配置文件中、开发配置文件中和默认配置文件中。

通过使用@ActiveProfiles(“dev”)注释TransferServiceTest，我们指示Spring TestContext框架加载ApplicationContext，其中活动配置文件设置为{“dev”}。结果，创建了一个嵌入式数据库并填充了测试数据，并且count RepositoryBean连接了对开发DataSource的引用。这很可能是我们在集成测试中想要的。

有时将Bean分配给默认配置文件很有用。只有当没有特别激活其他配置文件时，才会包含默认配置文件中的Bean。您可以使用它来定义要在应用程序的默认状态中使用的“回退”Bean。例如，您可以显式地为开发和生产配置文件提供数据源，但在这两个配置文件都不活动时将内存中的数据源定义为默认数据源。

下面的代码清单演示了如何使用@configuration类而不是XML来实现相同的配置和集成测试：

在这个变体中，我们将XML配置拆分成四个独立的@Configuration类：

与基于XML的配置示例一样，我们仍然使用@ActiveProfiles(“dev”)注释TransferServiceTest，但这次我们使用@ConextConfiguration注释指定了所有四个配置类。测试类本身的主体完全保持不变。

通常的情况是，在给定项目中的多个测试类中使用一组配置文件。因此，为了避免重复声明@ActiveProfiles注释，您可以在基类上声明一次@ActiveProfiles，子类会自动从基类继承@ActiveProfiles配置。在下面的示例中，@ActiveProfiles(以及其他批注)的声明已移动到抽象超类AbstractIntegrationTest：

@ActiveProfiles还支持可用于禁用活动配置文件继承的inheritProfiles属性，如下例所示：

此外，有时有必要以编程方式来解析测试的活动配置文件，而不是声明式的 - ，例如，基于：

要以编程方式解析活动的Bean定义配置文件，您可以实现一个自定义的ActiveProfilesResolver，并使用@ActiveProfiles的解析器属性注册它。有关更多信息，请参阅相应的javadoc。以下示例演示如何实现和注册自定义OperatingSystemActiveProfilesResolver：

Spring框架对具有属性源层次结构的环境的概念提供了一流的支持，并且您可以使用特定于测试的属性源来配置集成测试。与@Configuration类上使用的@PropertySource注释不同，您可以在测试类上声明@TestPropertySource注释，以声明测试属性文件或内联属性的资源位置。这些测试属性源被添加到为带注释的集成测试加载的ApplicationContext的环境中的PropertySources集合中。

从Spring Framework5.2.5开始，TestContext框架通过@DynamicPropertySource注释提供对动态属性的支持。此批注可用于需要将具有动态值的属性添加到为集成测试加载的ApplicationContext的Environment中的PropertySources集合的集成测试中。

与在类级别应用的@TestPropertySource批注不同，@DynamicPropertySource必须应用于接受单个DynamicPropertyRegistry参数的静态方法，该参数用于将名称-值对添加到Environment。值是动态的，并通过供应商提供，该供应商仅在解析属性时调用。通常，方法引用用于提供值，如下面的示例所示，该示例使用TestContainers项目在SpringApplicationContext外部管理Redis容器。托管Redis容器的IP地址和端口通过redis.host和redis.port属性提供给测试的ApplicationContext中的组件。这些属性可以通过Spring的Environment抽象访问，也可以直接注入到Spring管理的组件中--例如，分别通过@Value(“${redis.host}”)和@Value(“${redis.port}”)。

要指示TestContext框架加载WebApplicationContext而不是标准的ApplicationContext，您可以使用@WebAppConfiguration注释相应的测试类。

测试类上的@WebAppConfiguration指示TestContext框架(TCF)应该为您的集成测试加载WebApplicationContext(WAC)。在后台，TCF确保创建了MockServletContext并将其提供给测试的WAC。默认情况下，MockServletContext的基本资源路径设置为src/main/webapp。这被解释为相对于JVM根目录的路径(通常是项目的路径)。如果您熟悉Maven项目中Web应用程序的目录结构，您就知道src/main/webapp是WAR根目录的默认位置。如果需要覆盖此默认设置，您可以提供指向<代码>@WebAppConfiguration 批注的替代路径(例如，@WebAppConfiguration(“src/test/webapp”)).如果希望从类路径而不是文件系统引用基本资源路径，可以使用Spring的classpath：前缀。

注意，Spring对WebApplicationContext实现的测试支持与对标准ApplicationContext实现的支持不相上下。当使用WebApplicationContext进行测试时，您可以使用@ConextConfiguration声明XML配置文件、Groovy脚本或@Configuration类。您还可以自由使用任何其他测试注释，例如@ActiveProfiles、@TestExecutionListeners、@SQL、@Rollback等。

本节中的其余示例显示了用于加载WebApplicationContext的一些不同配置选项。下面的示例显示了TestContext框架对约定优先于配置的支持：

如果您使用@WebAppConfiguration注释测试类，而没有指定资源基础路径，则资源路径实际上默认为file：src/main/webapp。类似地，如果您声明@ConextConfiguration而没有指定资源位置、组件类或上下文初始值设定项，则Spring会尝试使用约定(即WacTest-context.xml与WacTest类或静态嵌套的@Configuration类位于同一个包中)来检测配置的存在。

以下示例显示如何使用@WebAppConfiguration显式声明资源基本路径，并使用@ConextConfiguration显式声明XML资源位置：

这里需要注意的重要一点是，具有这两个注释的路径的语义不同。默认情况下，@WebAppConfiguration资源路径是基于文件系统的，而@ConextConfiguration资源位置是基于类路径的。

下面的示例显示，我们可以通过指定一个Spring资源前缀来覆盖这两个批注的默认资源语义：

将本例中的注释与上一个示例进行对比。

为了提供全面的Web测试支持，TestContext框架有一个默认启用的ServletTestExecutionListener。当针对 TestExecutionListener>WebApplicationContext进行测试时，这个 会在每个测试方法之前使用Spring Web的 RequestContextHolder来设置默认的线程本地状态，并基于 @WebAppConfiguration配置的基本资源路径创建一个 MockHttpServletRequest、一个 MockHttpServletResponse和一个 ServletWebRequest。 ServletTestExecutionListener还确保 MockHttpServletResponse和 ServletWebRequest可以注入到测试实例中，并在测试完成后清除线程本地状态。

一旦您为您的测试加载了一个WebApplicationContext，您可能会发现您需要与Web模拟 - 交互，以设置您的测试夹具或在调用您的Web组件之后执行断言。下面的示例显示了哪些模拟可以自动连接到您的测试实例中。注意，WebApplicationContext和MockServletContext都是跨测试套件缓存的，而其他mock则由ServletTestExecutionListener管理每个测试方法。

一旦TestContext框架加载了一个测试的ApplicationContext(或WebApplicationContext)，该上下文就会被缓存，并在同一测试套件中声明相同的唯一上下文配置的所有后续测试中重复使用。要了解缓存的工作原理，重要的是要了解什么是“唯一的”和“测试套件”。

ApplicationContext可以由用于加载它的配置参数的组合唯一标识。因此，配置参数的唯一组合被用来生成用于缓存上下文的键。TestContext框架使用以下配置参数来构建上下文缓存键：

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

上下文高速缓存的大小以默认的最大大小32为界。只要达到最大大小，就会使用最近最少使用(LRU)逐出策略来逐出和关闭陈旧的上下文。通过设置名为spring.test.context.cache.maxSize.的jvm系统属性，可以从命令行或构建脚本配置最大大小或者，您可以通过SpringProperties机制设置相同的属性。

由于在给定测试套件中加载大量应用程序上下文可能会导致套件花费不必要的长时间来运行，因此准确地知道加载和缓存了多少上下文通常是有益的。要查看底层上下文缓存的统计信息，您可以将调试日志类别的日志级别设置为<org.springframework.test.context.cache>调试 。

在测试损坏应用程序上下文并需要重新加载的情况下(例如，通过修改应用程序对象的Bean定义或状态)，您可以使用@DirtiesContext注释您的测试类或测试方法(请参阅Spring测试注释中@DirtiesContext的讨论)。这将指示Spring从缓存中删除上下文并重新构建应用程序上下文，然后再运行需要相同应用程序上下文的下一个测试。请注意，对@DirtiesContext注释的支持是由DirtiesContextBeforeModesTestExecutionListener和DirtiesContextTestExecutionListener，提供的，它们在默认情况下处于启用状态。