单元测试构建文件的最佳策略是什么？
我问的原因是我的公司生产高度可靠的嵌入式设备。软件补丁不是一种选择，因为它们花费了我们的客户数千美元来分发。因此，我们有非常严格的代码质量程序（单元测试、代码审查、可追溯性等）。这些程序正在应用于我们的构建文件（如果你必须知道，我希望是自动工具），但如果感觉就像一个 hack。
呃......项目编译......将构建文件标记为已审核和单元测试。
必须有更好的方法。想法？
问问题
894 次
3 回答
6
这是我们在跨十几个平台构建大型代码库（数百万行代码）时所采用的方法。
- Makefile 更改由构建团队审核。 这些人知道人们在我们的构建环境中容易犯的错误，并且当构建中断时，他们是首当其冲的人，因此他们有动力去发现问题。
- 尽量减少 Makefile 中的内容，因此出错的机会更少。我们在 make 之上有一个层，用于生成 Makefile。开发人员只需要在更高级别的文件中使用标签来指示，例如给定的目标是共享库或单元测试。通常在一行上定义一个目标，然后在生成的 Makefile 中产生多个设置/目标。类似的事情也可以用scons 之类的构建工具来完成，它允许人们抽象出平台特定细节之类的东西，从而使目标变得非常简单。
- 我们的构建工具的单元测试。 该工具是用 Perl 编写的，因此我们在那里使用 Perl 的Test::More单元测试框架来验证该工具是否根据我们的更高级别文件生成正确的 Makefile。如果我们改用 scons 之类的东西，我会使用他们的测试框架。
- 我们每晚构建/测试脚本的单元测试。 我们有一组脚本，可以在每个平台上开始每晚构建、运行静态分析工具、运行单元测试、运行功能测试，并将所有结果报告给中央数据库。我们单独测试各种脚本，主要使用 sh/bash/ksh/etc 的shunit2单元测试框架。
- 我们的构建/测试过程的端到端测试。 我正在做一个端到端的测试，它在一个很小的源代码树上运行，而不是我们的生产代码，因为后者可能需要几个小时才能构建。这些测试主要是为了验证我们的构建目标是否仍然有效，并将结果报告到我们的中央数据库中，例如，升级我们的代码覆盖工具或更改我们的构建脚本。
于 2009-05-14T13:42:50.013 回答
2
让您的构建文件编译您的软件的已知版本（或从构建角度来看类似的更简单的代码段），并将使用新构建工具获得的结果与预期结果（使用经过验证的构建工具版本构建）进行比较）。
于 2009-05-14T14:57:51.767 回答
-2
在我的项目中，构建文件不会经常更改。更重要的是，我可以重用早期项目中的构建文件，只需更改一些变量（我将其移至易于识别的部分）。这就是为什么对我来说不需要对构建文件进行单元测试。在其他项目中可能会有所不同。
于 2009-05-14T13:45:28.137 回答