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

openstack rdo

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

这如何转化为包装界？ 作为规范文件的一部分，我们可以定义％check部分，在其中添加脚本以测试已安装的代码。 尽管这不是Fedora打包指南中的强制性部分，但强烈建议您这样做，因为它可以很好地保证打包的代码是正确的。

在许多情况下，RDO软件包的规范中都包含此％check部分，并且在构建软件包时将执行项目的单元测试。 这是为python-oslo-utils包执行的单元测试的示例 。

“但是为什么包装时又要再次执行这些测试？” Ÿ欧可以问。 毕竟，这些相同的测试在合并之前由Zuul门执行。 好吧，这有很多原因：

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

• 使用pip将项目依赖项安装在OpenStack Gate中，某些版本可能有所不同。 这是因为OpenStack项目为每个依赖项支持多种版本，但通常仅使用一个版本进行测试。 我们已经看到了这样的情况：项目声明支持库的x.0版本，但随后添加了需要x.1版本的代码。 这种变化不会被OpenStack门注意到，但是会使打包时的单元测试失败。

• 它们还使我们能够在上游闸门中发现问题之前将其发现。 OpenStack项目使用需求项目来决定其他项目应使用自己的库的哪个版本。 这允许出现一些相互依赖的问题，其中Oslo库中的更改可能会发现另一个项目中的错误，但是直到用新版本的Oslo库更新需求项目后，该问题才引起注意。 在RDO情况下，我们在所有项目中使用master分支中的代码运行RDO干线构建器，这使我们能够提前通知，如本示例bug所示 。

• 当新的依赖项已添加到项目中时，它们会向我们发出预警，但它们尚未包含在软件包规格中。 由于单元测试使用大多数代码，因此任何缺少的依赖关系都应使它们失败。

由于在包构建过程中执行单元测试的方式，因此在定义它们时需要牢记一些细节。 如果您作为开发人员关注他们，则将使包装商的生活更轻松：

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

• 尝试将单元测试的运行时间保持在合理的范围内。 如果一个项目的单元测试需要1个小时才能完成，那么很可能在打包过程中将不会执行它们，例如在本示例中 。

• 不要以为总是会在具有8个快速核心的机器上执行单元测试。 我们已经看到，在有限的环境中运行或者单元测试花费的时间超过一定时间时，单元测试会失败。

既然您知道单元测试对于RDO封装的重要性，那么您可以继续进行并确保我们在每个包装上都使用它。 骇客骇客！

---

想更多地了解打包和安装OpenStack？ OpenStack峰会将于5月 21 日 至24日 在温哥华 举行，这 是一次学习更多有关此主题的绝好机会。 本文还发布在RDO Project博客上 。

翻译自: https://opensource.com/article/18/5/unit-tests-rdo-package-builds

openstack rdo