单元测试构建文件

Question

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

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

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

必须有一个更好的方法.想法？

Answer 1

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

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