Spring 5 中文解析之测试篇-集成测试(中)

技术交流群：

3.5 Spring TestContext框架

Spring TestContext 框架（位于org.springframework.test.context包中）提供了通用的、注解驱动的单元和集成测试支持，这些支持与所使用的测试框架无关。TestContext框架还非常重视约定优于配置，你可以通过基于注解的配置覆盖合理的默认值。

除了通用测试基础结构之外，TestContext框架还为JUnit 4，JUnit Jupiter（AKA JUnit 5）和TestNG提供了显式支持。对于JUnit 4和TestNG，Spring提供了抽象支持类。此外，Spring为JUnit 4提供了自定义JUnit Runner和自定义JUnit规则，以及JUnit Jupiter的自定义扩展，可让你编写所谓的POJO测试类。不需要POJO测试类来扩展特定的类层次结构，例如抽象支持类。下一节概述了TestContext框架的内部。如果你仅对使用框架感兴趣，而对使用自己的自定义监听器或自定义加载程序进行扩展不感兴趣，请直接转到配置（上下文管理 、依赖项注入、事务管理、支持类和注解支持部分。

3.5.1 关键抽象

该框架的核心由TestContextManager类和TestContext，TestExecutionListener和SmartContextLoader接口组成。为每个测试类创建一个TestContextManager（例如，用于在JUnit Jupiter中的单个测试类中执行所有测试方法）。反过来，TestContextManager管理包含当前测试上下文的TestContext。随着测试的进行，TestContextManager还更新了TestContext的状态，并委托给TestExecutionListener实现，该实现通过提供依赖项注入，管理事务等来检测实际的测试执行。SmartContextLoader负责为给定的测试类加载ApplicationContext。有关更多信息和各种实现的示例，请参见javadoc和Spring测试套件。

TestContext

TestContext封装了在其中执行测试的上下文（与使用中的实际测试框架无关），并为其负责的测试实例提供了上下文管理和缓存支持。如果需要，TestContext还委托给SmartContextLoader来加载ApplicationContext。

TestContextManager

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

• 在任何before类之前或在特定测试框架的所有方法之前。
• 测试实例后处理。
• 在任何before或在每个特定测试框架的方法之前。
• 在执行测试方法之前但在测试设置之后。
• 在测试方法执行之后，但在测试拆卸之前。
• 之后的任何方法或之后的每一个特定的测试框架。
• 在特定测试框架的任何类后或所有方法之后。

TestExecutionListener

TestExecutionListener定义用于对由注册监听器的TestContextManager发布的测试执行事件做出反应的API。请参阅TestExecutionListener配置。

上下文加载器

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

SmartContextLoader是ContextLoader接口的扩展，它取代了原始的最小ContextLoader SPI。具体来说，SmartContextLoader可以选择处理资源位置、组件类或上下文初始化器。此外，SmartContextLoader可以在其加载的上下文中设置激活Bean定义配置文件并测试属性源。

Spring提供了以下实现：

• DelegatingSmartContextLoader: 它是两个默认加载器之一，它在内部委派给AnnotationConfigContextLoader、GenericXmlContextLoader或GenericGroovyXmlContextLoader，具体取决于为测试类声明的配置或默认位置或默认配置类的存在。仅当Groovy在类路径上时才启用Groovy支持。
• WebDelegatingSmartContextLoader: 它是两个默认加载器之一，它在内部委派给AnnotationConfigWebContextLoader、GenericXmlWebContextLoader或GenericGroovyXmlWebContextLoader，具体取决于为测试类声明的配置或默认位置或默认配置类的存在。仅当测试类上存在@WebAppConfiguration时，才使用Web ContextLoader。仅当Groovy在类路径上时才启用Groovy支持。
• AnnotationConfigContextLoader:从组件类加载标准ApplicationContext。
• AnnotationConfigWebContextLoader: 从组件类加载WebApplicationContext。
• GenericGroovyXmlContextLoader: 从Groovy脚本或XML配置文件的资源位置加载标准ApplicationContext。
• GenericGroovyXmlWebContextLoader: 从Groovy脚本或XML配置文件的资源位置加载WebApplicationContext。
• GenericXmlContextLoader: 从XML资源位置加载标准ApplicationContext。
• GenericXmlWebContextLoader: 从XML资源位置加载WebApplicationContext。
• GenericPropertiesContextLoader：从Java属性文件加载标准ApplicationContext。

3.5.2 引导TestContext框架

Spring TestContext 框架内部的默认配置足以满足所有常见用例。但是，有时开发团队或第三方框架希望更改默认的ContextLoader，实现自定义的TestContext或ContextCache，扩展默认的ContextCustomizerFactory和TestExecutionListener实现等等。为了对TestContext框架的运行方式进行低级别控制，Spring提供了引导策略。

TestContextBootstrapper定义了用于引导TestContext框架的SPI。TestContextManager使用TestContextBootstrapper加载当前测试的TestExecutionListener实现并构建它管理的TestContext。你可以直接使用@BootstrapWith或作为元注解，为测试类（或测试类层次结构）配置自定义引导策略。如果没有通过使用@BootstrapWith显式配置引导程序，则根据@WebAppConfiguration的存在，使用DefaultTestContextBootstrapper或WebTestContextBootstrapper。

由于TestContextBootstrapper SPI将来可能会更改（以适应新的需求），我们强烈建议实现者不要直接实现此接口，而应扩展AbstractTestContextBootstrapper或其具体子类之一。

3.5.3 TestExecutionListener配置

Spring提供了以下TestExecutionListener实现，这些实现默认情况下按以下顺序注册：

• ServletTestExecutionListener:为WebApplicationContext配置Servlet API模拟。
• DirtiesContextBeforeModesTestExecutionListener:处理before模式的@DirtiesContext注解。
• DependencyInjectionTestExecutionListener: 为测试实例提供依赖项注入。
• DirtiesContextTestExecutionListener: 处理after模式的@DirtiesContext注解。
• TransactionalTestExecutionListener: 提供具有默认回滚语义的事务测试执行。
• SqlScriptsTestExecutionListener: 运行使用@Sql注释配置的SQL脚本。
• EventPublishingTestExecutionListener: 将测试执行事件发布到测试的ApplicationContext中（请参阅测试执行事件）。

注册TestExecutionListener实现

你可以使用@TestExecutionListeners注解为测试类及其子类注解TestExecutionListener实现。有关详细信息和示例，请参见注解支持和@TestExecutionListeners的javadoc。

默认TestExecutionListener实现自动发现

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

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

TestExecutionListener顺序实现

当TestContext框架通过上述SpringFactoriesLoader机制发现默认TestExecutionListener实现时，实例化的监听器将使用Spring的AnnotationAwareOrderComparator进行排序，该类将使用Spring的Ordered接口和@Order注解进行排序。Spring提供的AbstractTestExecutionListener和所有默认的TestExecutionListener实现以适当的值实现Ordered。因此，第三方框架和开发人员应通过实施Ordered或声明@Order来确保按默认顺序注册其默认的TestExecutionListener实现。请参阅javadoc以获取核心默认TestExecutionListener实现的getOrder()方法，以获取有关为每个核心监听器分配哪些值的详细信息。

TestExecutionListener合并实现

如果通过@TestExecutionListeners注册了自定义TestExecutionListener，则不会注册默认监听器。在大多数常见的测试方案中，这有效地迫使开发人员手动声明除任何自定义监听器之外的所有默认监听器。

下面的清单演示了这种配置样式：

@ContextConfiguration
@TestExecutionListeners({
   
    MyCustomTestExecutionListener.class,
    ServletTestExecutionListener.class,
    DirtiesContextBeforeModesTestExecutionListener.class,
    DependencyInjectionTestExecutionListener.class,
    DirtiesContextTestExecutionListener.class,
    TransactionalTestExecutionListener.class,
    SqlScriptsTestExecutionListener.class
})
class MyTest {
   
    // class body...
}

这种方法的挑战在于，它要求开发人员确切地知道默认情况下注册了哪些监听器。此外，默认的监听器集可以随版本的不同而变化-例如，在Spring框架4.1中引入了SqlScriptsTestExecutionListener，在Spring框架4.2中引入了DirtiesContextBeforeModesTestExecutionListener。此外，诸如Spring Boot和Spring Security之类的第三方框架通过使用上述自动发现机制注册了自己的默认TestExecutionListener实现。

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

例如，如果上一个示例中的MyCustomTestExecutionListener类将顺序值（例如500）配置为小于ServletTestExecutionListener的顺序（恰好是1000），则MyCustomTestExecutionListener可以自动与默认列表合并。在ServletTestExecutionListener前面，并且前面的示例可以替换为以下示例：

@ContextConfiguration
@TestExecutionListeners(
    listeners = MyCustomTestExecutionListener.class,
    mergeMode = MERGE_WITH_DEFAULTS
)
class MyTest {
   
    // class body...
}

3.5.4 测试执行事件

Spring框架5.2中引入的EventPublishingTestExecutionListener提供了一种实现自定义TestExecutionListener的替代方法。测试的ApplicationContext中的组件可以监听EventPublishingTestExecutionListener发布的以下事件，每个事件都与TestExecutionListener API中的方法相对应。

• BeforeTestClassEvent
• PrepareTestInstanceEvent
• BeforeTestMethodEvent
• BeforeTestExecutionEvent
• AfterTestExecutionEvent
• AfterTestMethodEvent
• AfterTestClassEvent

只有当ApplicationContext已经加载时，才会发布这些事件。

这些事件可能由于各种原因被使用，例如重置模拟bean或跟踪测试执行。使用测试执行事件而不是实现自定义TestExecutionListener的一个优势是，测试执行事件可以由在测试ApplicationContext中注册的任何Spring bean所使用，并且此类bean可以直接受益于依赖项注入和ApplicationContext的其他功能。相反，TestExecutionListener在ApplicationContext中不是bean。

为了监听测试执行事件，Spring Bean可以选择实现org.springframework.context.ApplicationListener接口。或者，可以使用@EventListener注解监听器方法，并将监听方法配置为监听上面列出的特定事件类型之一（请参阅基于注解的事件监听器）。由于这种方法的流行，Spring提供了以下专用的@EventListener注解，以简化测试执行事件监听器的注册。这些注解驻留在org.springframework.test.context.event.annotation包中。

• @BeforeTestClass
• @PrepareTestInstance
• @BeforeTestMethod
• @BeforeTestExecution
• @AfterTestExecution
• @AfterTestMethod
• @AfterTestClass

参考代码：org.liyong.test.annotation.test.spring.TestExecutionEventTest

异常处理

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

异步监听器

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

参考代码：org.liyong.test.annotation.test.spring.TestExecutionEventTest

3.5.5 上下文管理

每个TestContext为其负责的测试实例提供上下文管理和缓存支持。测试实例不会自动接收对配置的ApplicationContext的访问。但是，如果测试类实现ApplicationContextAware接口，则将对ApplicationContext的引用提供给测试实例。请注意，AbstractJUnit4SpringContextTests和AbstractTestNGSpringContextTests实现了ApplicationContextAware，因此可以自动提供对ApplicationContext的访问。

@Autowired ApplicationContext

作为实现ApplicationContextAware接口的替代方法，你可以通过字段或setter方法上的@Autowired注解为测试类注入应用程序上下文，如以下示例所示：

@SpringJUnitConfig
class MyTest {
    

 @Autowired //1
 ApplicationContext applicationContext;

 // class body...
}

1. 注入ApplicationContext。

同样，如果将测试配置为加载WebApplicationContext，则可以将Web应用程序上下文注入到测试中，如下所示：

@SpringJUnitWebConfig //1
class MyWebAppTest {
    

    @Autowired //2
    WebApplicationContext wac;

    // class body...
}

1. 配置WebApplicationContext
2. 注入WebApplicationContext

使用@Autowired的依赖关系注入是DependencyInjectionTestExecutionListener提供的，它是默认配置的（参见测试装置的依赖注入）。

使用TestContext框架的测试类不需要扩展任何特定的类或实现特定的接口来配置其应用程序上下文。而是通过在类级别声明@ContextConfiguration注解来实现配置。如果你的测试类未明确声明应用程序上下文资源位置或组件类，则配置的ContextLoader将确定如何从默认位置或默认配置类加载上下文。除了上下文资源位置和组件类之外，还可以通过应用程序上下文初始化程序配置应用程序上下文。

以下各节说明如何使用Spring的@ContextConfiguration注解通过XML配置文件、Groovy脚本、组件类（通常为@Configuration类）或上下文初始化器来配置测试ApplicationContext。另外，你可以为高级用例实现和配置自己的自定义SmartContextLoader。

• 通过XML资源配置上下文
• 通过Groovy脚本配置上下文
• 通过组件类配置上下文
• XML、Groovy脚本、组件类混合
• 通过上下文初始化器配置上下文
• 上下文配置继承
• 通过环境配置配置上下文
• 通过测试属性源配置上下文
• 通过动态属性源配置上下文
• 加载 WebApplicationContext
• 上下文缓存
• 上下文层级

通过XML资源配置上下文

若要使用XML配置文件为测试加载ApplicationContext，请使用@ContextConfiguration注解测试类，并使用包含XML配置元数据的资源位置的数组配置locations属性。简单路径或相对路径（例如context.xml）被视为相对于定义测试类的程序包的类路径资源。以斜杠开头的路径被视为绝对类路径位置（例如:/org/example/config.xml）。照原样使用表示资源URL的路径（即以classpath：、file：、http：等开头的路径）。

@ExtendWith(SpringExtension.class)
// ApplicationContext从根路径加载"/app-config.xml" 和
// "/test-config.xml"
@ContextConfiguration(locations={
   "/app-config.xml", "/test-config.xml"}) //1
class MyTest {
   
    // class body...
}

1. 将locations属性设置为XML文件列表。

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

@ExtendWith(SpringExtension.class)
@ContextConfiguration({
   "/app-config.xml", "/test-config.xml"}) //1
class MyTest {
   
    // class body...
}

1. 不使用location属性指定XML文件。

如果你从@ContextConfiguration注解中省略了位置和值属性，则TestContext框架将尝试检测默认的XML资源位置。具体而言，GenericXmlContextLoader和GenericXmlWebContextLoader根据测试类的名称检测默认位置。如果你的类名为com.example.MyTest则GenericXmlContextLoader将classpath:com/example/MyTest-context.xml加载应用程序上下文。以下示例显示了如何执行此操作：

@ExtendWith(SpringExtension.class)
// ApplicationContext will be loaded from
// "classpath:com/example/MyTest-context.xml"
@ContextConfiguration //1
class MyTest {
   
    // class body...
}

1. 从默认位置加载配置。

通过Groovy脚本配置上下文

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

激活Groovy脚本支持

如果类路径中有Groovy，那么就会自动启用使用Groovy脚本在Spring TestContext框架中加载ApplicationContext的支持。

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

@ExtendWith(SpringExtension.class)
// ApplicationContext will be loaded from "/AppConfig.groovy" and
// "/TestConfig.groovy" in the root of the classpath
@ContextConfiguration({
   "/AppConfig.groovy", "/TestConfig.Groovy"}) 
class MyTest {
   
    // class body...
}

如果你从@ContextConfiguration注解中省略了location和value属性，则TestContext框架将尝试检测默认的Groovy脚本。具体来说，GenericGroovyXmlContextLoader和GenericGroovyXmlWebContextLoader根据测试类的名称检测默认位置。如果你的类名为com.example.MyTest则Groovy上下文加载器将从classpath:com/example/MyTestContext.groovy加载应用程序上下文。下面的示例演示如何使用默认值：

@ExtendWith(SpringExtension.class)
// ApplicationContext will be loaded from
// "classpath:com/example/MyTestContext.groovy"
@ContextConfiguration //1
class MyTest {
   
    // class body...
}

1. 从默认位置加载配置。

同时声明XML配置和Groovy脚本

你可以使用@ContextConfiguration的location或value属性同时声明XML配置文件和Groovy脚本。如果到配置的资源位置的路径以.xml结尾，则使用XmlBeanDefinitionReader加载该路径。否则，将使用GroovyBeanDefinitionReader加载它。

以下清单显示了如何在集成测试中将两者结合起来：

@ExtendWith(SpringExtension.class)
// ApplicationContext将从
// "/app-config.xml" 和 "/TestConfig.groovy"加载上下文
@ContextConfiguration({
     "/app-config.xml", "/TestConfig.groovy" })
class MyTest {
    
 // class body...
}

通过组件类配置上下文

要使用组件类（请参见基于Java的容器配置）为测试加载ApplicationContext，可以使用@ContextConfiguration注解测试类，并使用包含对组件类的引用的数组来配置classes属性。以下示例显示了如何执行此操作：

@ExtendWith(SpringExtension.class)
// ApplicationContext将从AppConfig和TestConfig加载上下文
@ContextConfiguration(classes = {
   AppConfig.class, TestConfig.class}) //1
class MyTest {
   
    // class body...
}

1. 指定组件类。

组件类

术语组件类可以指以下任何一种：

• 用@Configuration注解的类。
• 组件（即，用@Component、@Service、@Repository或其他构造型注解注释的类）。
• 与JSR-330兼容的类，该类使用javax.inject注解进行了注释。
• 包含@Bean方法的任何类。
• 打算注册为Spring组件的任何其他类（即ApplicationContext中的Spring bean），可能利用单个自动构造函数的自动装配而无需使用Spring注解。

有关组件类的配置和语义的更多信息，请参见@Configuration和@Bean的javadoc，尤其要注意@Bean Lite模式的讨论。

如果你从@ContextConfiguration注解中省略了classes属性，则TestContext框架将尝试检测默认配置类的存在。具体来说，AnnotationConfigContextLoader和AnnotationConfigWebContextLoader检测到满足配置类实现要求的测试类的所有静态嵌套类，如@Configuration javadoc中所指定。请注意，配置类的名称是任意的。另外，如果需要，一个测试类可以包含多个静态嵌套配制类。在以下示例中，OrderServiceTest类声明一个名为Config的静态嵌套配置类，该配置类将自动用于为测试类加载ApplicationContext：

@SpringJUnitConfig //1
// ApplicationContext将从内部潜逃静态累加载
class OrderServiceTest {
   

    @Configuration
    static class Config {
   

        // this bean will be injected into the OrderServiceTest class
        @Bean
        OrderService orderService() {
   
            OrderService orderService = new OrderServiceImpl();
            // set properties, etc.
            return orderService;
        }
    }

    @Autowired
    OrderService orderService;

    @Test
    void testOrderService() {
   
        // test the orderService
    }

}

1. 从嵌套的Config类加载配置信息。

XML、Groovy脚本、组件类混合

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

此外，某些第三方框架（例如Spring Boot）提供了一流的支持，可以同时从不同类型的资源（例如XML配置文件、Groovy脚本和@Configuration类）中加载ApplicationContext。过去，Spring框架不支持此标准部署。因此，Spring框架在spring-test模块中提供的大多数SmartContextLoader实现对于每个测试上下文仅支持一种资源类型。但是，这并不意味着你不能同时使用两者。通用规则的一个例外是GenericGroovyXmlContextLoader和GenericGroovyXmlWebContextLoader同时支持XML配置文件和Groovy脚本。此外，第三方框架可以选择通过@ContextConfiguration支持位置和类的声明，并且，借助TestContext框架中的标准测试支持，你可以选择以下选项。

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

通过上下文初始化器配置上下文

若要使用上下文初始化程序为你的测试配置ApplicationContext，请使用@ContextConfiguration注解测试类，并使用包含对实现ApplicationContextInitializer的类的引用的数组配置初始化程序属性。然后，使用声明的上下文初始值设定项来初始化为测试加载的ConfigurableApplicationContext。请注意，每个声明的初始化程序支持的具体ConfigurableApplicationContext类型必须与使用中的SmartContextLoader创建的ApplicationContext类型（通常是GenericApplicationContext）兼容。此外，初始化程序的调用顺序取决于它们是实现Spring的Ordered接口还是以Spring的@Order注解或标准的@Priority注解进行注释。下面的示例演示如何使用初始化程序：

@ExtendWith(SpringExtension.class)
// ApplicationContext将从TestConfig
// 和 通过TestAppCtxInitializer初始化
@ContextConfiguration(
    classes = TestConfig.class,
    initializers = TestAppCtxInitializer.class) //1
class MyTest {
   
    // class body...
}

1. 使用配置类和初始化程序指定配置。

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

@ExtendWith(SpringExtension.class)
// ApplicationContext will be initialized by EntireAppInitializer
// which presumably registers beans in the context
@ContextConfiguration(initializers = EntireAppInitializer.class) //1
class MyTest {
   
    // class body...
}

1. 仅使用初始化程序来指定配置。

参考代码：org.liyong.test.annotation.test.spring.ContextInitializerTests

上下文配置继承

@ContextConfiguration支持boolean inheritLocations和inheritinitialalizer属性，它们表示是否应该继承由超类声明的资源位置或组件类和上下文初始化器。这两个标志的默认值为true。这意味着测试类将继承资源位置或组件类以及任何超类申明的上下文初始化器。具体来说，将测试类的资源位置或组件类附加到由超类申明的资源位置或带注解的类的列表中。同样，将给定测试类的初始化程序添加到由测试超类定义的初始化程序集。因此，子类可以选择扩展资源位置、组件类或上下文初始化程序。

如果@ContextConfiguration中的inheritLocations或inheritInitializers属性被设置为false，则测试类的资源位置或组件类和上下文初始化器将分别有效地替代超类定义的配置。

在下一个使用XML资源位置的示例中，从Base-config.xml和Extended-config.xml依次加载ExtendedContext的ApplicationContext。因此，extended-config.xml中定义的Bean可以覆盖（即替换）base-config.xml中定义的那些。以下示例显示了一个类如何扩展另一个类并使用其自己的配置文件和超类的配置文件：

@ExtendWith(SpringExtension.class)
// ApplicationContext将从类路径根目录加载"/base-config.xml"
@ContextConfiguration("/base-config.xml") //1
class BaseTest {
   
    // class body...
}

// ApplicationContext将从类路径根目录加载"/base-config.xml" 和
// "/extended-config.xml"
@ContextConfiguration("/extended-config.xml"