为什么我们在 RDO 的 OpenStack 软件包构建中使用测试

单元测试用于验证各个源代码单元是否按照已定义的规范（spec）工作。 虽然这听起来可能很难理解，但简而言之，这意味着我们尝试验证我们源代码的每个部分是否按预期工作，而无需运行它们所属的完整程序。

所有 OpenStack 项目都自带一套单元测试，例如，这里 是 oslo.config 项目的单元测试文件夹。 当为审查提出新补丁时，会执行这些测试，以确保现有（或新的）功能不会因新代码而损坏。 例如，如果您查看 此审查，您可以看到执行的持续集成作业之一是 “openstack-tox-py27”，它使用 Python 2.7 运行单元测试。

这如何转化为软件包构建领域？ 作为 spec 文件的一部分，我们可以定义一个 %check 部分，我们在其中添加脚本来测试已安装的代码。 虽然这不是 Fedora 软件包指南 中的强制性部分，但强烈建议这样做，因为它提供了良好的保证，确保打包的代码是正确的。

在许多情况下，RDO 软件包在其 spec 中包含此 %check 部分，并且在构建软件包时执行项目的单元测试。 这是 一个示例，展示了为 python-oslo-utils 软件包执行的单元测试。

“但是为什么在打包时再次执行这些测试？” 您可能会问。 毕竟，这些相同的测试在合并之前由 Zuul gate 执行。 好吧，这有很多原因

• 这些单元测试是在特定的操作系统版本和特定的软件包集下运行的。 这些可能与 RDO 使用的不同，因此我们需要确保项目与这些组件的兼容性。

• 项目依赖项在 OpenStack gate 中使用 pip 安装，并且某些版本可能不同。 这是因为 OpenStack 项目支持每个依赖项的一系列版本，但通常只使用一个版本进行测试。 我们已经看到一些案例，项目声明支持库 x.0 版本，但随后添加了需要 x.1 版本的代码。 OpenStack gate 不会注意到此更改，但这会导致单元测试在打包时失败。

• 它们还允许我们在上游 gate 中发生问题之前检测到问题。 OpenStack 项目使用 requirements 项目 来决定其他项目应使用其自身库的哪个版本。 这允许一些相互依赖的问题，其中 Oslo 库中的更改可能会暴露另一个项目中的错误，但在 requirements 项目更新为 Oslo 库的新版本之前不会被注意到。 在 RDO 案例中，我们使用来自所有项目 master 分支的代码运行 RDO trunk 构建器，这允许我们提前通知，例如 此示例错误 中所示。

• 当项目中添加了新的依赖项，但它们尚未在软件包 spec 中时，它们会给我们早期警告。 由于单元测试会执行大部分代码，因此任何缺失的依赖项都应使其失败。

由于单元测试在软件包构建期间的执行方式，因此在定义它们时需要记住一些细节。 如果您作为开发人员遵循这些细节，您将使打包人员的生活更轻松

• 不要创建依赖于 Internet 上可用资源的单元测试。 大多数打包环境在构建软件包时不允许访问 Internet，因此依赖于通过 DNS 解析 IP 地址的单元测试将失败。

• 尽量将单元测试运行时控制在合理的范围内。 如果一个项目的单元测试需要 1 小时才能完成，则它们很可能不会在打包期间执行，例如 此示例 中所示。

• 不要假设单元测试总是在具有 8 个快速内核的机器上执行。 我们已经看到一些案例，单元测试在受限环境中运行时失败，或者 当它们花费超过一定时间才能完成时。

现在您已经了解了单元测试对于 RDO 打包的重要性，您可以继续确保我们在每个软件包上都使用它。 祝您编程愉快！

想了解更多关于打包和安装 OpenStack 的信息？ OpenStack 峰会 将于 5 月 21 日至 24 日在温哥华举行，这是一个了解更多关于此主题的绝佳机会。 本文也发布在 RDO 项目博客 上。