单元测试构建文件

Question

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

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

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

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

Answer 1

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

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

Answer 2

让您的构建文件编译的软件（或者更简单的一段代码是从构建的角度类似）的已知版本，并与新的构建工具获得的预期结果比较的结果（建成了经过验证的版本构建工具）。

Answer 3

在我的项目建设，文件不经常改变。甚至，我可以从早期的项目中重用内建文件，只改变一些变量（即我搬到了一个易于识别的部分）。这就是为什么对我来说是不需要进行单元测试集结文件。这可以是在其他项目不同。