我见过在src/test/resources下定义独立application.properties的项目，其中包含在src/main/resources下定义的默认application.properties中的所有属性，同时覆盖用于测试的属性。这种方法的缺点是，每次更改(添加/删除/更新属性(都必须在application.properties中完成，否则测试可能会失败。
另一方面，我看到的项目中，在src/test/resources下只定义了一个基于上下文的属性文件，比如application-test.properties，其中只包含用于测试目的的覆盖属性。该方法合并了src/main/resources下的默认application.properties和src/test/resources下的application-test.properties。相应的上下文必须通过@ActiveProfiles在测试类中激活，比如@ActiveProfiles("test")
你采用的方法是什么？为什么？对此有什么最佳实践或建议吗？
感谢您提前回复。
配置文件通常用于；地图"；不同的春豆。我看到人们在大多数工作流程中通常坚持使用其中三种：development、test和production——主要是在教程和博客中。
我使用与应用程序将要部署的实际环境一致的配置文件，因为它更现实。所以我总是使用local配置文件运行测试。如果我需要任何特定的设置来运行测试，我只需在src/test/resources下重新定义一个application.properties文件并覆盖所需内容。
通过这种方式，您将始终有效地拥有在src/main/resources中的每个环境中运行应用程序所要使用的内容，如果有任何内容需要被覆盖仅用于测试，src/test/resources/application.properties可以处理它。
例如，假设您的src/main/resources/application.yaml文件看起来像：
application:
key: value-common
another-key: value-common-another
spring:
profiles:
active: default
---
spring:
config:
activate:
on-profile: local
main:
banner-mode: console
---
spring:
config:
activate:
on-profile: test
这有效地定义了两个配置文件：local和test——因为default具有两者的共同点。现在，如果在src/test/resources中放置一个包含以下内容的application.properties文件：
application.key: value-common-test
一切都将保持不变，但当您运行测试(对于任何配置文件(时，application.key将绑定到value-common-test。如果您刚好运行应用程序，它将绑定到value-common。