单元测试是否应该作为构建的一部分执行？

#1 楼

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


构建中断更少，主构建中断几乎为零
组件/集成级别测试的附加测试覆盖范围
通过识别孤立地通过但在实验室运行中失败或在不同语言版本上失败的测试（测试用例可靠性）
，并在测试过程中积极吸引开发人员
使单元测试对整个团队透明（如果UT失败，则会记录错误）

一些潜在的注意事项


如果您认为增加代码覆盖率= =更好的测试，并且可能掩盖标记为覆盖区域的分析（如果进行白盒结构分析）
增加了测试运行时间（可能是在资源有限的小型商店中起诉）

#2 楼

单元测试应始终作为构建的一部分运行。在我们的项目中，我们已经这样做了2年多，其收益总是大于弊端。不仅这些与构建一起运行，而且我们具有适当的检查，当覆盖率低于某个特定阈值时，该构建就会中断构建（尽管我在代码覆盖方面对Bj表示赞同！=良好测试）。我们看到的一些好处：


这给团队带来了紧迫感，使单元测试始终保持绿色，否则构建会中断。这样可以减少开发人员在一段时间内的破坏构建，而可以在提交代码之前在执行单元测试时更加严格地执行代码。可以使用Sonar之类的工具在一段时间内分析覆盖率和单元测试执行趋势，以检测出灰点并确定需要改进的地方。 CI。
它是您的第一道防线，以防您需要“连续交付”之类的东西，使软件在投入生产之前会经过许多自动的关卡/检查（整个过程的大部分自动）。
这样更透明，有效。（想想分布在全球各地的分布式团队在不同时区以相同的代码库工作）
它是您的单位级回归套件（应该添加一个错误）作为单元级别的测试）。

一些需要注意的事情：


代码覆盖率具有误导性，因为覆盖率只有80％意味着从未测试过20％的代码。因此，单元测试应该是有意义的，并且只有在与构建一起运行时才有用。构建如此之多，以至于无法获得任何有意义的快速反馈。

#3 楼

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


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

以下是在将构建提供给QA团队之前运行单元测试用例的优点。


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

#4 楼

为了便于讨论...正确完成单元测试存在一些实际缺点-


每个新功能都应添加新测试，并且您不能发布代码在测试准备就绪之前（我知道，您可以说可以根据需要修改规则，并且进行单元测试是一件好事）。
进行主要的API更改时，您将不得不重写测试，可能需要一段时间。请参阅“您可以在上面辩护”）
根据我的经验，即使没有单元测试，CI也往往足够脆弱。