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

###### 3.5.5 上下文管理



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



**@Autowired ApplicationContext**

>

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

>

```java

@SpringJUnitConfig

class MyTest {



@Autowired //1

ApplicationContext applicationContext;



// class body...

}

```

>

1. 注入ApplicationContext。

>

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

>

```java

@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配置文件](https://docs.spring.io/spring/docs/5.2.7.RELEASE/spring-framework-reference/testing.html#testcontext-ctx-management-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加载它。

>

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

>

```java

@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](https://docs.spring.io/spring-framework/docs/5.2.7.RELEASE/javadoc-api/org/springframework/context/annotation/Bean.html)的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") //2
class ExtendedTest extends BaseTest {
    // class body...
}



1. 在超类中定义的配置文件

2. 子类中定义的配置文件。



同样，在下一个使用组件类的示例中，从BaseConfig和ExtendedConfig类按该顺序加载ExtendedTest的ApplicationContext。因此，在ExtendedConfig中定义的Bean可以覆盖（即替换）在BaseConfig中定义的Bean。下面的示例显示一个类如何扩展另一个类，并同时使用自己的配置类和超类的配置类：



// ApplicationContext从BaseConfig加载
@SpringJUnitConfig(BaseConfig.class) //1
class BaseTest {
    // class body...
}
// ApplicationContext将从BaseConfig和ExtendedConfig加载
@SpringJUnitConfig(ExtendedConfig.class) //2
class ExtendedTest extends BaseTest {
    // class body...
}



1. 在超类中定义的配置类

2. 在子类中定义的配置类。



在使用上下文初始化程序的下一个示例中，通过使用BaseInitializer和ExtendedInitializer初始化ExtendedTest的ApplicationContext。但是请注意，初始化程序的调用顺序取决于它们是实现Spring的Ordered接口还是以Spring的@Order注解或标准的@Priority注解进行注释。以下示例显示了一个类如何扩展另一个类并使用其自己的初始化程序和超类的初始化程序：



// ApplicationContext将通过BaseInitializer初始化
@SpringJUnitConfig(initializers = BaseInitializer.class) //1
class BaseTest {
    // class body...
}
// ApplicationContext将通过BaseInitializer
// 和 ExtendedInitializer初始化
@SpringJUnitConfig(initializers = ExtendedInitializer.class) //2
class ExtendedTest extends BaseTest {
    // class body...
}



1. 超类中定义的初始化器。

2. 子类中定义的初始化程序。



使用环境配置文件进行上下文配置



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



你可以将@ActiveProfiles与SmartContextLoader SPI的任何实现一起使用，但较早的ContextLoader SPI的实现不支持@ActiveProfiles。



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



<!-- app-config.xml -->
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jdbc="http://www.springframework.org/schema/jdbc"
    xmlns:jee="http://www.springframework.org/schema/jee"
    xsi:schemaLocation="...">
    <bean id="transferService"
            class="com.bank.service.internal.DefaultTransferService">
        <constructor-arg ref="accountRepository"/>
        <constructor-arg ref="feePolicy"/>
    </bean>
    <bean id="accountRepository"
            class="com.bank.repository.internal.JdbcAccountRepository">
        <constructor-arg ref="dataSource"/>
    </bean>
    <bean id="feePolicy"
        class="com.bank.service.internal.ZeroFeePolicy"/>
    <beans profile="dev">
        <jdbc:embedded-database id="dataSource">
            <jdbc:script
                location="classpath:com/bank/config/sql/schema.sql"/>
            <jdbc:script
                location="classpath:com/bank/config/sql/test-data.sql"/>
        </jdbc:embedded-database>
    </beans>
    <beans profile="production">
        <jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
    </beans>
    <beans profile="default">
        <jdbc:embedded-database id="dataSource">
            <jdbc:script
                location="classpath:com/bank/config/sql/schema.sql"/>
        </jdbc:embedded-database>
    </beans>
</beans>



@ExtendWith(SpringExtension.class)
// ApplicationContext will be loaded from "classpath:/app-config.xml"
@ContextConfiguration("/app-config.xml")
@ActiveProfiles("dev")
class TransferServiceTest {
    @Autowired
    TransferService transferService;
    @Test
    void testTransferService() {
        // test the transferService
    }
}



运行TransferServiceTest时，会从类路径根目录中的app-config.xml配置文件中加载其ApplicationContext。如果检查app-config.xml，可以看到accountRepository bean对dataSource bean有依赖性。但是，dataSource未被定义为顶级bean。相反，dataSource定义了三次：在生产配置文件中、在开发配置文件中以及在默认配置文件中。



通过使用@ActiveProfiles（“dev”）注解TransferServiceTest，我们指示Spring TestContext 框架加载具有设置为{“dev”}的激活配置文件的ApplicationContext。结果，创建了一个嵌入式数据库，并用测试数据填充了数据库，并用对开发DataSource的引用来连接accountRepository bean。这可能是我们在集成测试中想要的。



有时将bean分配给默认配置文件很有用。只有在没有特别激活其他配置文件时，才会包含缺省配置文件中的bean。你可以使用它来定义在应用程序的默认状态中使用的后备bean。例如，你可以显式提供dev和production的数据源，但是当两者都不处于活动状态时，将内存中数据源定义为默认值。



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



@Configuration
@Profile("dev")
public class StandaloneDataConfig {
    @Bean
    public DataSource dataSource() {
        return new EmbeddedDatabaseBuilder()
            .setType(EmbeddedDatabaseType.HSQL)
            .addScript("classpath:com/bank/config/sql/schema.sql")
            .addScript("classpath:com/bank/config/sql/test-data.sql")
            .build();
    }
}



@Configuration
@Profile("production")
public class JndiDataConfig {
    @Bean(destroyMethod="")
    public DataSource dataSource() throws Exception {
        Context ctx = new InitialContext();
        return (DataSource) ctx.lookup("java:comp/env/jdbc/datasource");
    }
}



@Configuration
@Profile("default")
public class DefaultDataConfig {
    @Bean
    public DataSource dataSource() {
        return new EmbeddedDatabaseBuilder()
            .setType(EmbeddedDatabaseType.HSQL)
            .addScript("classpath:com/bank/config/sql/schema.sql")
            .build();
    }
}



@Configuration
public class TransferServiceConfig {
    @Autowired DataSource dataSource;
    @Bean
    public TransferService transferService() {
        return new DefaultTransferService(accountRepository(), feePolicy());
    }
    @Bean
    public AccountRepository accountRepository() {
        return new JdbcAccountRepository(dataSource);
    }
    @Bean
    public FeePolicy feePolicy() {
        return new ZeroFeePolicy();
    }
}



@SpringJUnitConfig({
        TransferServiceConfig.class,
        StandaloneDataConfig.class,
        JndiDataConfig.class,
        DefaultDataConfig.class})
@ActiveProfiles("dev")
class TransferServiceTest {
    @Autowired
    TransferService transferService;
    @Test
    void testTransferService() {
        // test the transferService
    }
}



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



• ransferServiceConfig: 通过使用@Autowired进行依赖项注入来获取数据源。

• StandaloneDataConfig: 为适合开发人员测试的嵌入式数据库定义数据源。

• JndiDataConfig: 定义在生产环境中从JNDI检索的数据源。

• DefaultDataConfig: 如果没有配置文件处于激活状态，则为默认的嵌入式数据库定义一个数据源。



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



在一个给定项目中，跨多个测试类使用一组配置文件是很常见的。因此，为避免@ActiveProfiles注解的重复声明，可以在基类中声明一次@ActiveProfiles，子类会自动从基类继承@ActiveProfiles配置。在以下示例中，@ActiveProfiles的声明（以及其他注解）已移至抽象超类AbstractIntegrationTest：



@SpringJUnitConfig({
        TransferServiceConfig.class,
        StandaloneDataConfig.class,
        JndiDataConfig.class,
        DefaultDataConfig.class})
@ActiveProfiles("dev")
abstract class AbstractIntegrationTest {
}



// "dev"配置集成父类
class TransferServiceTest extends AbstractIntegrationTest {
    @Autowired
    TransferService transferService;
    @Test
    void testTransferService() {
        // test the transferService
    }
}



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



// "dev"配置被"production"覆盖
@ActiveProfiles(profiles = "production", inheritProfiles = false)
class ProductionTransferServiceTest extends AbstractIntegrationTest {
    // test body
}



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



• 当前的操作系统。

• 是否在持续集成构建服务器上执行测试。

• 存在某些环境变量。

• 自定义类级别注释的存在。

• 其他问题。



要以编程方式解析活动bean定义配置文件，可以实现自定义ActiveProfilesResolver并使用@ActiveProfiles的resolver属性对其进行注册。有关更多信息，请参见相应的javadoc。下面的示例演示如何实现和注册自定义的OperatingSystemActiveProfilesResolver：



// "dev"配置通过自定义解析器编程式地覆盖
@ActiveProfiles(
        resolver = OperatingSystemActiveProfilesResolver.class,
        inheritProfiles = false)
class TransferServiceTest extends AbstractIntegrationTest {
    // test body
}



public class OperatingSystemActiveProfilesResolver implements ActiveProfilesResolver {
    @Override
    public String[] resolve(Class<?> testClass) {
        String profile = ...;
        // determine the value of profile based on the operating system
        return new String[] {profile};
    }
}



通过测试属性源配置上下文



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



你可以将@TestPropertySource与SmartContextLoader SPI的任何实现一起使用，但是较早的ContextLoader SPI的实现不支持@TestPropertySource。

>

SmartContextLoader的实现可通过MergedContextConfiguration中的getPropertySourceLocations()和getPropertySourceProperties()方法访问合并的测试属性源值。



声明测试属性源



你可以使用@TestPropertySource的location或value属性来配置测试属性文件。



支持传统属性文件格式和基于XML的属性文件格式，例如： classpath：/com/example/test.properties或file：///path/to/file.xml。



每个路径都被解析为Spring资源。普通路径（例如 test.properties）被视为相对于定义测试类的程序包的类路径资源。以斜杠开头的路径被视为绝对类路径资源（例如：/org/example/test.xml）。通过使用指定的资源协议加载引用URL的路径（例如，以classpath：、file：或http：为前缀的路径）。不允许使用资源位置通配符（例如* /.properties）每个位置都必须精确评估为一个.properties或.xml资源。



以下示例使用测试属性文件：



@ContextConfiguration
@TestPropertySource("/test.properties") //1
class MyIntegrationTests {
    // class body...
}



1. 指定具有绝对路径的属性文件。



你可以使用@TestPropertySource的properties属性，以键/值对的形式配置内联属性，如下例所示。所有键值对都作为优先级最高的单个测试PropertySource添加到封闭环境中。



键值对支持的语法与为Java属性文件中的条目定义的语法相同：



• key=value

• key:value

• key value



下面的示例设置两个内联属性：



@ContextConfiguration
@TestPropertySource(properties = {"timezone = GMT", "port: 4242"}) //1
class MyIntegrationTests {
    // class body...
}



1. 通过使用键值语法的两种变体来设置两个属性。



从Spring框架5.2开始，@TestPropertySource可以用作可重复注解。这意味着你可以在单个测试类上具有@TestPropertySource的多个声明，其后的@TestPropertySource注解中的locations和properties将覆盖先前的@TestPropertySource注解中的locations和properties。

>

此外，你可以在一个测试类上声明多个组合注解，每个注解都用@TestPropertySource进行元注解，所有这些@TestPropertySource声明都将贡献给你的测试属性源。直接呈现的@TestPropertySource注解总是优先于元呈现的@TestPropertySource注解。换句话说，直接存在的@TestPropertySource注解中的locations和properties将覆盖@TestPropertySource注解中用作元注解的locations和properties。



默认属性文件检测



如果@TestPropertySource被声明为空注解（即，没有locations或properties的显式值），则尝试检测相对于声明该注解的类的默认属性文件。例如，如果带注解的测试类是com.example.MyTest，则相应的对应属性文件是classpath:com/example/MyTest.properties。如果无法检测到默认值，则抛出IllegalStateException。



优先顺序



测试属性的优先级高于在操作系统环境、Java系统属性或应用程序通过使用@PropertySource声明性地或以编程方式添加的属性源中定义的属性。因此，测试属性可用于有选择地覆盖从系统和应用程序属性源加载的属性。此外，内联属性优先于从资源位置加载的属性。但是请注意，通过@DynamicPropertySource注册的属性比通过@TestPropertySource加载的属性具有更高的优先级。



在下一个示例中，timezone和port属性以及在/test.properties中定义的任何属性都将覆盖在系统和应用程序属性源中定义的同名属性。此外，如果/test.properties文件定义了timezone和port属性的条目，则这些条目将被使用properties属性声明的内联属性所覆盖。



@ContextConfiguration
@TestPropertySource(
    locations = "/test.properties",
    properties = {"timezone = GMT", "port: 4242"}
)
class MyIntegrationTests {
    // class body...
}



继承和覆盖测试属性源



@TestPropertySource支持布尔型的inheritLocations和inheritProperties属性，它们表示属性文件的资源位置和超类声明的内联属性是否应该被继承。这两个标志的默认值为true。这意味着测试类将继承任何超类声明的位置和内联属性。具体来说，测试类的位置和内联属性附加到父类声明的位置和内联属性。因此，子类可以选择扩展位置和内联属性。注意，后面出现的属性会隐藏(即覆盖)前面出现的同名属性。此外，前面提到的优先规则也适用于继承的测试属性源。



如果@TestPropertySource中的InheritLocations或InheritProperties属性设置为false，则分别为测试类设置位置或内联属性，并有效替换超类定义的配置。



在下一个示例中，BaseTest的ApplicationContext是通过只使用base加载的。属性文件作为测试属性源。相反，ExtendedTest的ApplicationContext是通过使用base加载的属性和扩展。属性文件作为测试属性源位置。下面的示例演示如何使用属性文件在子类及其超类中定义属性：



```java

@TestPropertySource("base.properties")

@ContextConfiguration

class BaseTest {

// ...

}



@TestPropertySource("extended.properties")

@ContextConfiguration

class ExtendedTest extends BaseTest {

// ...

}

```



在下一个示例中，仅使用内联的key1属性来加载BaseTest的ApplicationContext。相反，使用内联的key1和key2属性来加载ExtendedTest的ApplicationContext。下面的示例演示如何通过使用内联属性在子类及其父类中定义属性：



@TestPropertySource(properties = "key1 = value1")
@ContextConfiguration
class BaseTest {
    // ...
}
@TestPropertySource(properties = "key2 = value2")
@ContextConfiguration
class ExtendedTest extends BaseTest {
    // ...
}



通过动态属性源配置上下文



从Spring框架5.2.5开始，TestContext框架通过@DynamicPropertySource注解提供对动态属性的支持。此注解可用于需要向为集成测试加载的ApplicationContext的环境中的PropertySources集添加带有动态值的属性的集成测试。



@DynamicPropertySource注解及其支持的基础结构最初旨在使基于Testcontainers的测试中的属性易于暴露于Spring集成测试。但是，此功能还可以用于其生命周期在测试的ApplicationContext之外维护的任何形式的外部资源。



与在类级别应用@TestPropertySource注解相反，@DynamicPropertySource必须应用于接受单个DynamicPropertyRegistry参数的静态方法，该参数用于向环境添加名称/值对。值是动态的，并通过Supplier提供，只有在解析属性时才调用Supplier。通常，方法引用被用来提供值，如下面的例子所示，它使用Testcontainers项目在Spring ApplicationContext之外管理一个Redis容器。通过redis.host和redis.port属性，测试的ApplicationContext中的组件可以使用托管Redis容器的IP地址和端口。这些属性可以通过Spring的环境抽象访问，或者直接注入到Spring管理的组件中，例如分别通过@Value("${redis.host}")和@Value("${redis.port}")。



@SpringJUnitConfig(/* ... */)
@Testcontainers
class ExampleIntegrationTests {
    @Container
    static RedisContainer redis = new RedisContainer();
    @DynamicPropertySource
    static void redisProperties(DynamicPropertyRegistry registry) {
        registry.add("redis.host", redis::getContainerIpAddress);
        registry.add("redis.port", redis::getMappedPort);
    }
    // tests ...
}



优先顺序



动态属性的优先级高于@TestPropertySource、操作系统的环境、Java系统属性或应用程序通过@PropertySource声明性地或以编程方式添加的属性源中加载的属性。因此，动态属性可用于有选择地覆盖通过@TestPropertySource、系统属性源和应用程序属性源加载的属性。



**加载WebApplicationContext**



若要指示TestContext框架加载WebApplicationContext而不是标准ApplicationContext，可以使用@WebAppConfiguration注解各自的测试类。