单元测试构建文件

Question

单元测试构建文件的最佳策略是什么？

我问的原因是我的公司生产高度可靠的嵌入式设备。 软件补丁不是一种选择，因为分发它们需要我们的客户花费数千美元。 因此，我们有非常严格的代码质量程序（单元测试、代码审查、可追溯性等）。 这些程序正在应用于我们的构建文件（如果您必须知道的话，我希望遗憾的是自动工具），但感觉就像是黑客。

呃...项目编译...将构建文件标记为已审查和单元测试。

必须有更好的方法。 有想法吗？

Answer 1

这是我们在跨十几个平台构建大型代码库（数百万行代码）时所采取的方法。

• Makefile 更改由构建团队审核。这些人知道人们在我们的构建环境中容易犯的错误，并且当构建中断时他们是首当其冲的人，因此他们有动力去发现问题。
• 最大限度地减少 Makefile 中需要的内容，从而减少出错的机会。 我们在 make 之上有一个层，用于生成 Makefile。 开发人员只需在更高级别的文件中使用标签来指示，例如给定的目标是共享库或单元测试。 通常，一个目标定义在一行上，然后在生成的 Makefile 中产生多个设置/目标。 类似的事情可以使用诸如 scons 之类的构建工具来完成，这些工具允许人们抽象出特定于平台的详细信息等内容，使目标变得非常简单。
• 我们的构建工具的单元测试。该工具是用 Perl 编写的，因此我们使用 Perl 的 Test::More 单元测试框架用于验证该工具是否根据我们的更高级别文件生成了正确的 Makefile。 如果我们使用 scons 之类的东西，我会使用他们的测试框架。
• 我们的夜间构建/测试脚本的单元测试。我们有一组脚本，可以在每个平台上启动夜间构建，运行静态分析工具，运行单元测试，运行功能测试，并将所有结果报告给中央数据库。 我们单独测试各种脚本，主要使用 sh/bash 的 shunit2 单元测试框架/ksh/等。
• 我们的构建/测试过程的端到端测试。我正在开展一个端到端测试，该测试在一个微小的源代码树上运行，而不是在我们的生产代码上运行，因为后者可能需要几个小时建造。 这些测试主要旨在验证我们的构建目标是否仍然有效，并将结果报告到我们的中央数据库中，即使在升级我们的代码覆盖工具或更改我们的构建脚本之后也是如此。

Answer 2

让您的构建文件编译软件的已知版本（或者从构建角度来看类似的更简单的代码），并将使用新构建工具获得的结果与预期结果（使用经过验证的构建工具版本构建）进行比较）。

Answer 3

在我的项目中，构建文件不会经常更改。 更重要的是，我可以重用早期项目中的构建文件，只更改一些变量（我将其移至易于识别的部分）。 这就是为什么对我来说不需要对构建文件进行单元测试。 这在其他项目中可能有所不同。