确保各个代码单元按预期工作对于减少错误和意外行为至关重要。
单元测试用于验证源代码的各个单元是否按照定义的规范工作。虽然这听起来很复杂，但简而言之，这意味着我们要验证源代码的每个部分是否按预期工作，而不必运行它们所属的整个程序。
所有的OpenStack项目都有自己的一套单元测试，例如，这是oslo的单元测试文件夹。配置项目。这些测试是在提出一个新补丁供评审时执行的，以确保现有(或新)功能不会被新代码破坏。例如，如果检查这篇综述，您可以看到执行的一个持续集成作业是“openstack-tox-py27”，它使用Python 2.7运行单元测试。
RDO单位
这如何转化为包装世界?作为spec文件的一部分，我们可以定义%check部分，在这里我们添加脚本来测试安装的代码。虽然这不是Fedora打包指南中的强制部分，但强烈建议这样做，因为它可以很好地保证打包的代码是正确的。
在许多情况下，RDO包在它们的规范中包含这个%check部分，并且在构建包时执行项目的单元测试。这是为python-oslo-utils包执行的单元测试的一个示例。
您可能会问:“但是为什么在打包时要重新执行这些测试呢?”毕竟，这些相同的测试是在合并之前由Zuul gate执行的。原因有很多:
这些单元测试是在特定的操作系统版本和特定的包集上运行的。它们可能与RDO使用的不同，所以我们需要确保项目与那些组件的兼容性。
项目依赖项使用pip安装在OpenStack gate中，有些版本可能会有所不同。这是因为OpenStack项目为每个依赖项支持一系列的版本，但通常只测试一个版本。我们已经看到过项目声明支持版本x的情况。0的库，但随后添加了需要版本x.1的代码。OpenStack gate不会注意到这个变化，但是它会使单元测试在打包时失败。
它们还允许我们在问题发生在上游通道之前进行检测。OpenStack项目使用requirements项目来决定其他项目应该使用他们自己的库的哪个版本。这允许了一些相互依赖的问题，在这些问题中，Oslo库的变更可能会在另一个项目中发现一个bug，但是直到需求项目被Oslo库的新版本更新时才会被注意到。在RDO的情况下，我们在所有项目中使用来自主分支的代码运行RDO trunk builder，这允许我们提前通知，就像在这个示例bug中一样。
当新的依赖项被添加到项目中时，它们会给我们一个早期的警告，但是它们还没有出现在包规范中。由于单元测试测试大部分代码，任何缺少的依赖项都会使它们失败。
由于在包构建期间执行单元测试的方式，在定义它们时需要记住一些细节。如果你是一名开发人员，你会让他们的生活更容易:
不要创建依赖于Internet上可用资源的单元测试。大多数打包环境在构建包时不允许Internet访问，因此依赖于通过DNS解析IP地址的单元测试将失败。
尽量将单元测试运行时间保持在合理的范围内。如果一个项目的单元测试需要1个小时才能完成，那么它们很可能不会在打包过程中执行，如本例中所示。
不要假设单元测试总是在拥有8个快速核心的机器上执行。我们已经看到过单元测试失败的案例，比如在有限的环境中运行，或者需要超过一定时间才能完成。
既然您已经了解了RDO打包的单元测试的重要性，那么您可以继续并确保我们在每个包上都使用它。
