在持续集成（CI）中，首先运行快速且基础的测试。

虽然保持CI/CD 流程快速非常重要，但在很多情况下，你甚至不需要运行所有测试就能获得所需的反馈。

单元测试运行速度最快，因为它们测试的只是一小段代码，并且与系统的其他部分完全隔离。例如，它们通常不会涉及数据库。

单元测试处理的是基本业务逻辑，数量也最多，这在测试金字塔图中通常有所体现：

单元测试失败表明存在根本性问题，这使得运行剩余的高级和长时间运行的测试变得无关紧要。

鉴于这些原因，运行时间超过一分钟的测试套件项目应在持续集成 (CI) 过程中优先考虑单元测试。

如何先使用流水线运行快速测试

经典的持续集成设置是将所有测试拆分成并行作业：

在这种方法中，CI 构建的总时间取决于最慢的并行作业的持续时间。例如：

• 如果一些单元测试在不到一分钟的时间内失败，
• 但其中一个包含用户界面测试的作业运行了 6 分钟，
• 然后您需要等待 6 分钟才能收到有关单元测试失败的报告。

失败的单元测试通常会导致一些更高级别的测试也失败。然而，在这种情况下，更高级别测试的结果无关紧要，运行它们只会浪费时间和资源。

更好的方法是使用可定制的CI/CD 流水线。这样，您可以配置单个或并行作业的顺序块。一旦某个块失败，流水线就会停止。

这种策略可以让开发人员在几秒钟内获得关于细微错误的反馈。它还能促使所有团队成员了解随着代码库的增长，各个测试对性能的影响。

更多快速反馈技巧

您还可以使用其他策略来配合您的持续改进系统，从而快速获得反馈：

• 条件阶段执行允许您在合适的时机延迟运行构建的某些部分。例如，您可以配置 CI，使其仅在相关组件发生更改时才运行一部分端到端测试。
• 快速失败策略可在作业失败时提供即时反馈。一旦某个作业失败，持续集成 (CI) 系统会立即停止流水线中所有正在运行的作业。这种方法在运行持续时间可变的并行作业时尤为有效。
• 自动取消已排队的构建可以解决以下问题：当你推送了一些更改后，才发现遗漏了一些小细节，于是立即推送了一个新的版本，但之后却需要等待两倍的时间才能获得反馈。这种方法可以让你只收到重要版本的反馈，而跳过所有中间版本。

同样的原则也适用于交付流程中的各个阶段。例如，如果在部署后运行冒烟测试，则需要尽快发现问题。

您是如何快速获得反馈的？请在评论区留言。祝您开发愉快！