我们在签入之前运行单元测试，并在每个每日构建（功能分支）和每周构建（主分支；聚合多个功能分支）上将它们作为更大测试套件的一部分重新运行。

我们发现的一些优势包括：

• 更少的构建中断，主要的构建中断几乎为零
• 组件/集成级别测试的附加测试覆盖率
• 通过识别单独通过但在实验室运行或不同语言版本上失败的测试来帮助改进单元测试（测试用例可靠性）
• 并主动让开发人员参与测试过程
• 使单元测试对整个团队透明（如果 UT 失败，则会记录错误）

一些潜在的注意事项

• 如果您假设增加代码覆盖率 == 更好的测试，可能会导致对良好测试覆盖率的错误感觉，并且可能会掩盖对标记为已覆盖区域的分析（如果进行白盒结构分析）
• 增加了测试运行时间（在资源有限的小型商店中可能是一个问题）
• 过度依赖单元测试可能会导致错误的自信感，并导致测试人员无法在某些领域开发更健壮的测试

单元测试应始终作为构建的一部分运行。在我们的项目中，我们已经这样做了 2 年多，而且好处总是大于坏处。不仅这些与构建一起运行，而且我们还进行了检查，当覆盖率低于某个阈值时会中断构建（尽管我同意上面的 Bj 关于代码覆盖！= 良好的测试）。我们看到的一些好处：

1. 它给团队带来了一种紧迫感，要让单元测试始终保持绿色，否则构建会中断。随着开发人员在提交代码之前执行单元测试变得更加自律，这导致随着时间的推移更少的破坏构建。

2. 失败的测试总是会导致修复（测试或代码）。

3. 可以使用 Sonar 等工具在一段时间内分析代码覆盖率和单元测试执行趋势，以检测灰色点并确定需要改进的地方。

4. 作为 CI 的一部分，单元测试的安全网将始终涵盖重构。

5. 它充当第一道防线，以防您的目标是“持续交付”，在这种情况下，软件将在被推送到生产之前通过许多自动门/检查（并且整个过程的主要部分是自动的）。

6. 这种方式更加透明和有效。（想想分布在地球上的分布式团队在不同时区使用相同的代码库）

7. 它是您的单元级回归套件（应将发现的错误添加为单元级的测试）。

需要注意的一些事项：

1. 从某种意义上说，代码覆盖率具有误导性，即 80% 的覆盖率仅意味着 20% 的代码从未经过测试。所以单元测试应该是有意义的，并且只有在构建时运行它们才有用。

2. 这不应成为不进行系统/集成测试的借口。

3. 它不应该减慢构建速度，以至于否定任何有意义的快速反馈。

在由多个开发人员组成的团队中。

• 在签入代码之前，每个开发人员都应该对他们的模块进行单元测试
• 代码集成后，需要执行冒烟测试/基本测试用例来验证集成代码是否正常工作

以下是在向 QA 团队提供构建之前运行单元测试用例的优势

• 构建甚至可能会成功，而单元测试可能会失败。在将构建提供给 QA 团队之前可能会发现这种情况
• 这将有助于确定是否由于构建中丢失文件而导致失败
• 运行单元测试很好，您还可以运行基本的 P1 案例以确保功能正常运行
• 更早地检测到错误，减少修复它所需的成本

为了讨论......正确完成单元测试有一些真正的缺点 -

• 应该为每个新功能添加新的测试，并且您不能在测试准备好之前发布代码（我知道，您可以争辩说您可以在需要时改变规则，并且进行单元测试是一件好事）。

• 在进行重大 API 更改时，您将不得不重写测试，这可能需要一段时间。见“你可以在上面争论”）

• 根据我的经验，即使没有单元测试，CI 也很脆弱。