单元测试构建文件

Question

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

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

  

呃......项目编译......将构建文件标记为已审核并经过单元测试。

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

Answer 1

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

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

Answer 2

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

Answer 3

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