Spring中DynamicPropertySource使用指南-Java快速入门教程
1. 概述
今天的应用程序不是孤立的：我们通常需要连接到各种外部组件，如PostgreSQL，Apache Kafka，Cassandra，Redis和其他外部API。
在本教程中，我们将看到 Spring Framework 5.2.5 如何通过引入动态属性来促进测试此类应用程序。
首先，我们将从定义问题开始，看看我们过去是如何以不太理想的方式解决问题的。然后，我们将介绍@DynamicPropertySource注释，看看它如何为同一问题提供更好的解决方案。最后，我们还将看看测试框架中的另一种解决方案，与纯 Spring 解决方案相比，它可以更胜一筹。
2. 问题：动态属性
假设我们正在开发一个使用 PostgreSQL 作为其数据库的典型应用程序。我们将从一个简单的 JPA实体开始：
@Entity
@Table(name = "articles")
public class Article {
@Id
@GeneratedValue(strategy = IDENTITY)
private Long id;
private String title;
private String content;
// getters and setters
}
为了确保此实体按预期工作，我们应该为它编写一个测试来验证其数据库交互。由于此测试需要与真实数据库通信，因此我们应该事先设置一个 PostgreSQL 实例。
在测试执行期间，有不同的方法来设置此类基础结构工具。事实上，此类解决方案主要分为三类：
- 在某处设置单独的数据库服务器仅用于测试
- 使用一些轻量级、特定于测试的替代，例如 H2
- 让测试本身管理数据库的生命周期
由于我们不应该区分我们的测试和生产环境，因此与使用H2 等测试替代方案相比，有更好的替代方案。除了使用真实数据库之外，第三个选项还为测试提供了更好的隔离。此外，使用Docker和Testcontainers等技术，很容易实现第三种选择。
以下是我们使用 Testcontainers 等技术时我们的测试工作流程的样子：
- 在所有测试之前设置一个组件，如PostgreSQL。通常，这些组件侦听随机端口。
- 运行测试。
- 拆下组件。
如果我们的 PostgreSQL 容器每次都要侦听一个随机端口，那么我们应该以某种方式动态设置和更改spring.datasource.url配置属性。基本上，每个测试都应该有自己的配置属性版本。
当配置是静态的时，我们可以使用Spring Boot的配置管理工具轻松管理它们。但是，当我们面对动态配置时，相同的任务可能具有挑战性。
现在我们知道了问题所在，让我们看看它的传统解决方案。
3. 传统解决方案
实现动态属性的第一种方法是使用自定义应用程序上下文初始值设定项。基本上，我们首先设置我们的基础结构，然后使用第一步中的信息来自定义应用程序上下文：
@SpringBootTest
@Testcontainers
@ContextConfiguration(initializers = ArticleTraditionalLiveTest.EnvInitializer.class)
class ArticleTraditionalLiveTest {
@Container
static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:11")
.withDatabaseName("prop")
.withUsername("postgres")
.withPassword("pass")
.withExposedPorts(5432);
static class EnvInitializer implements ApplicationContextInitializer<ConfigurableApplicationContext> {
@Override
public void initialize(ConfigurableApplicationContext applicationContext) {
TestPropertyValues.of(
String.format("spring.datasource.url=jdbc:postgresql://localhost:%d/prop", postgres.getFirstMappedPort()),
"spring.datasource.username=postgres",
"spring.datasource.password=pass"
).applyTo(applicationContext);
}
}
// omitted
}
让我们来看看这个有点复杂的设置。JUnit 将先创建并启动容器。容器准备就绪后，Spring 扩展将调用初始值设定项以将动态配置应用于 Spring环境。显然，这种方法有点冗长和复杂。
只有在这些步骤之后，我们才能编写测试：
@Autowired
private ArticleRepository articleRepository;
@Test
void givenAnArticle_whenPersisted_thenShouldBeAbleToReadIt() {
Article article = new Article();
article.setTitle("A Guide to @DynamicPropertySource in Spring");
article.setContent("Today's applications...");
articleRepository.save(article);
Article persisted = articleRepository.findAll().get(0);
assertThat(persisted.getId()).isNotNull();
assertThat(persisted.getTitle()).isEqualTo("A Guide to @DynamicPropertySource in Spring");
assertThat(persisted.getContent()).isEqualTo("Today's applications...");
}4. @DynamicPropertySource
Spring Framework 5.2.5 引入了 @DynamicPropertySource注释，以便于添加具有动态值的属性。我们所要做的就是创建一个静态方法，该方法带有注释@DynamicPropertySource并且只有一个DynamicPropertyRegistry实例作为输入：
@SpringBootTest
@Testcontainers
public class ArticleLiveTest {
@Container
static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:11")
.withDatabaseName("prop")
.withUsername("postgres")
.withPassword("pass")
.withExposedPorts(5432);
@DynamicPropertySource
static void registerPgProperties(DynamicPropertyRegistry registry) {
registry.add("spring.datasource.url",
() -> String.format("jdbc:postgresql://localhost:%d/prop", postgres.getFirstMappedPort()));
registry.add("spring.datasource.username", () -> "postgres");
registry.add("spring.datasource.password", () -> "pass");
}
// tests are same as before
}
如上所示，我们在给定的 DynamicPropertyRegistry上使用add（String， Supplier<Object>） 方法来向 Spring环境添加一些属性。与我们之前看到的初始值设定项相比，这种方法要干净得多。请注意，注释为 @DynamicPropertySource的方法必须声明为静态，并且只能接受一个类型为 DynamicPropertyRegistry 的参数。
基本上，@DynmicPropertySource注释背后的主要动机是更容易地促进已经可能的事情。虽然它最初设计为与 Testcontainers 一起使用，但可以在我们需要处理动态配置的任何地方使用它。
5. 替代方案：测试工具
到目前为止，在这两种方法中，工具设置和测试代码都紧密交织在一起。有时，两个关注点的这种紧密耦合会使测试代码复杂化，尤其是当我们有多个东西要设置时。想象一下，如果我们在单个测试中使用PostgreSQL和Apache Kafka，基础设施设置会是什么样子。
除此之外，基础设施设置和应用动态配置将在所有需要它们的测试中重复。
为了避免这些缺点，我们可以使用大多数测试框架提供的测试工具设施。例如，在 JUnit 5 中，我们可以定义一个扩展，该扩展在测试类中的所有测试之前启动 PostgreSQL 实例，配置 Spring Boot，并在运行测试后停止 PostgreSQL 实例：
public class PostgreSQLExtension implements BeforeAllCallback, AfterAllCallback {
private PostgreSQLContainer<?> postgres;
@Override
public void beforeAll(ExtensionContext context) {
postgres = new PostgreSQLContainer<>("postgres:11")
.withDatabaseName("prop")
.withUsername("postgres")
.withPassword("pass")
.withExposedPorts(5432);
postgres.start();
String jdbcUrl = String.format("jdbc:postgresql://localhost:%d/prop", postgres.getFirstMappedPort());
System.setProperty("spring.datasource.url", jdbcUrl);
System.setProperty("spring.datasource.username", "postgres");
System.setProperty("spring.datasource.password", "pass");
}
@Override
public void afterAll(ExtensionContext context) {
// do nothing, Testcontainers handles container shutdown
}
}
在这里，我们实现了 AfterAllCallback 和BeforeAllCallback来创建 JUnit 5 扩展。这样，JUnit 5 将在运行所有测试之前执行beforeAll（） 逻辑，在运行测试后执行afterAll（） 方法中的逻辑。使用这种方法，我们的测试代码将像以下代码一样干净：
@SpringBootTest
@ExtendWith(PostgreSQLExtension.class)
@DirtiesContext
public class ArticleTestFixtureLiveTest {
// just the test code
}
在这里，我们还将@DirtiesContext注释添加到测试类中。重要的是，这重新创建了应用程序上下文，并允许我们的测试类与在随机端口上运行的单独 PostgreSQL 实例进行交互。因此，这会针对单独的数据库实例在彼此完全隔离的情况下执行我们的测试。
除了更具可读性之外，我们可以通过添加@ExtendWith（PostgreSQLExtension.class）注释来轻松重用相同的功能。没有必要像其他两种方法那样将整个PostgreSQL设置复制粘贴到我们需要的任何地方。
