unit-testing - 单元测试构建文件

Question

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

我问的原因是我的公司生产高度可靠的嵌入式设备。软件补丁不是一种选择，因为我们的客户需要花费数千美元来分发它们。因此，我们有非常严格的代码质量程序(单元测试、代码审查、可追溯性等)。这些程序被应用到我们的构建文件中(如果你必须知道 autotools，我期待遗憾)，但如果感觉像一个黑客。

Uh... the project compiles... mark the build files as reviewed and unit tested.

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

Answer 1

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

Makefile 更改由构建团队审核。 这些人知道人们在我们的构建环境中容易犯的错误，并且当构建失败时，他们首当其冲，因此他们有动力去发现问题。

最小化 Makefile 中需要的内容 ，因此出错的机会较少。我们在 make 之上有一个层，用于生成 Makefile。开发人员只需在更高级别的文件中使用标签指出，例如给定的目标是共享库或单元测试。通常在一行定义一个目标，然后在生成的 Makefile 中产生多个设置/目标。类似的事情可以用构建工具来完成，比如 scons这允许人们抽象出诸如特定于平台的细节之类的东西，使目标变得非常简单。

我们的构建工具的单元测试。 该工具是用 Perl 编写的，所以我们使用 Perl 的 Test::More单元测试框架用于验证该工具是否根据我们的更高级别文件生成了正确的 Makefile。如果我们使用 scons 之类的东西，我会使用 their testing framework .

我们每晚构建/测试脚本的单元测试。 我们有一组脚本，可以在每个平台上每晚开始构建、运行静态分析工具、运行单元测试、运行功能测试，并将所有结果报告给中央数据库。我们单独测试各种脚本，主要使用 shunit2 sh/bash/ksh/etc 的单元测试框架。

我们的构建/测试过程的端到端测试。 我正在研究一个端到端的测试，该测试在一个很小的源代码树上运行，而不是我们的生产代码，因为后者可能需要几个小时来构建。这些测试主要旨在验证我们的构建目标是否仍然有效并将结果报告到我们的中央数据库，例如，即使在升级我们的代码覆盖工具或对我们的构建脚本进行更改之后。