单元测试生成文件

Question

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

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

嗯..。这个项目汇编..。将构建文件标记为审阅和单元测试。

一定有更好的办法。想法？

Answer 1

下面是我们在十几个平台上构建大型代码库(数百万行代码)时所采用的方法。

• 生成文件更改由构建团队评审。这些人知道人们在我们的构建环境中往往会犯的错误，而且当构建中断时，他们感受到了最严重的错误，因此他们被激励去发现问题。
• 将Makefile中所需的内容降到最低，因此出错的机会更少。我们在make上面有一个层，它生成Makefile。开发人员只需在较高级别的文件中使用标记来指示，例如，给定的目标是共享库或单元测试。通常在一行中定义目标，然后在生成的Makefile中生成多个设置/目标。类似的事情可以用像斯康斯这样的构建工具来完成，这样就可以抽象出平台特定的细节，使目标变得非常简单。
• 单元测试我们的构建工具。这个工具是用Perl编写的，所以我们在那里使用Perl的测试：：更多单元测试框架来验证这个工具在我们更高级别的文件中是否生成了正确的Makefile。如果我们用scon之类的东西代替，我会使用他们的测试框架。
• 单元测试我们的夜间构建/测试脚本。我们有一组脚本，可以在每个平台上开始夜间构建，运行静态分析工具，运行单元测试，运行功能测试，并向中央数据库报告所有结果。我们单独测试各种脚本，主要使用sh/bash/ksh/等的shunit2单元测试框架。
• 对我们的构建/测试过程进行端到端的测试。我正在进行一个端到端的测试，它运行在一个很小的源代码树上，而不是我们的生产代码上，因为后者可能需要几个小时的时间来构建。这些测试的主要目的是验证我们的构建目标仍然工作，并将结果报告到我们的中央数据库，甚至在升级我们的代码覆盖率工具或修改我们的构建脚本之后。

Answer 2

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

Answer 3

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