优化 Spring ：可能会拖慢你速度的注释

我们都知道集成测试并不是运行速度最快的，它们肯定比单元测试花费更长的时间。

原因是您必须启动 Spring 上下文才能运行测试。您的应用程序越大，应用程序启动所需的时间就越长。

这可能会让您的团队不耐烦地等待测试运行，并开始跳过它们。此外，这甚至可能会阻止您的团队编写更多集成测试场景。

但您是否知道，根据您所做的事情，您可能会使测试花费的时间比应有的时间长？

一些简单的注释可以重新启动 Spring 上下文，使一切变慢！

那么让我们找出为什么会发生这种情况以及可能导致这种情况的原因。

为什么会出现这种情况？

Spring 中的@SpringBootTest注释允许您的测试套件对所有测试使用相同的上下文。

然后它将为所有集成测试重用相同的上下文。这可以节省一些执行时间，因为它不必再次启动 spring。

如果您不断在测试日志中看到 Spring 横幅和启动日志，则可能是某些原因导致重新启动。

会是什么呢？

发生这种情况是因为测试中的某些内容弄脏了上下文。这将在下一个测试类之前触发 Spring 上下文自动重启。

触发spring上下文重启的注解

@SpyBean：

问题：

在已运行的上下文中的现有 bean 中使用间谍（部分模拟）。这将使您的测试重新启动 spring 上下文，以用间谍 bean 替换原始 bean。

解决方案：

尝试在特定于您的测试的 @Configuation 类中定义 bean。或者创建一个像超类这样的中心点，您可以在其中定义所有测试注释和 @SpringBootTest。您将此间谍 bean 设为超类的属性，并使其可用于测试类。这将使间谍通过继承可用于您的测试类。但是这个间谍对于继承这个超类的所有类都是可用的。这不是最漂亮的解决方案，但它确实有效。您始终可以重新设计代码以避免使用 @SpyBean 注释

@AutoConfigureWiremock（它发生在版本 2.35.0 中，也许在最近的版本中已修复）：

默认情况下，@AutoConfigureWiremock将使用@AutoConfigureWiremock(port=0)进行配置。运行测试时它会为 Wiremock 分配一个随机端口。

问题：

在ATest类中使用@AutoConfigureWiremock(port=1212)，在BTest类中使用@AutoConfigureWiremock(port=3232)，Spring将重新启动上下文。

如果您不断更改存根路径，您也会遇到问题。ATest 使用：@AutoConfigureWiremock(port=0,stubs=”/src/resources/mappings/ATest”)。BTest 使用不同的路径：@AutoConfigureWiremock(port=0,stubs=”/src/resources/mappings/BTest”)。

解决方案：

使用wiremock @AutoConfigureWiremock(port=0) 的默认配置保留所有测试。

避免在不同的测试之间更改存根文件夹定义。

如果两者都不可行，您可以从测试到测试或从类到类创建一个新的wiremock 实例。使用这种方式可以避免使用注释@AutoConfigureWiremock。您可以使每个实例指向不同的存根文件夹。

但要小心，这样做你必须在 application.properties 中维护一个固定的 por。现在spring不再控制wiremock，这就是为什么它不会触发上下文重新启动。

@DirtiesContext(classMode = ClassMode.AFTER_EACH_TEST_METHOD)：

此注释将关闭并在测试环境中重新创建上下文。并且可以在某些时刻使用，例如：

• 在每个测试方法之前
• 测试方法后
• 考试课前
• 测试课后

问题：

注释的重点已经是重新启动上下文。开发人员通常使用此注释，因为测试在单独运行时有效，但在运行整个类时失败。发生这种情况是因为您的测试不是孤立的，并且一个测试的执行会影响另一个测试的行为。

解决方案：

编写彼此隔离的测试场景，并使每个场景都有其独特的数据。如果您需要包含一些数据的数据库表，请在测试之前创建它并在测试结束时删除它。

请记住，当您的系统在生产服务器中运行时，您的用户正在一起执行请求。您不会根据收到的每个请求重新启动 Spring 应用程序，那么为什么要在测试中执行此操作呢？

@MockBean

问题：

当 @MockBean 出现在类中时，ApplicationContext 缓存会被标记为脏。因此，运行程序将在测试类完成后清理缓存

解决方案：

您可以按照相同的步骤修复@SpyBean问题。

@TestPropertySource：

它定义的配置源的优先级高于项目中任何其他源。您还可以内联某些属性或为属性指定不同的位置。

问题：

通过在某些测试类中执行此操作，您将强制 Spring 重新启动，以用一些具有更高优先级的属性替换此属性。或者包含一些新属性，甚至在不同的文件夹中查找属性。

解决方案：

通过创建完全根据您的测试需求设置的测试应用程序属性来避免这种情况。一旦定义的属性是您的测试所独有的，Spring 将加载。

@ActiveProfiles(“测试”)

这使您能够从应用程序更改配置文件，并加载不同的 bean、属性等。

问题：

如果您更改此配置，每次测试您的 Spring 上下文将始终重新启动。它将应用更改并将 bean、属性和配置加载到特定配置文件。

解决方案：

您需要更改个人资料吗？您可以将您的配置聚合为一个吗？如果可以的话，就去做吧。如果没有，您可以通过创建一个中心点来减少损害，例如按配置文件对测试执行进行分组的超类。

第三方库内的注释。

问题

某些第三方库本身可能包含一些自动配置，并且可能会导致一些问题。这可能很难找到。

解决方案

找到它并不容易，因此请调查并尝试找到它。确保它是否不是您可以删除的东西，或者排除您未使用的依赖项的某些部分。