测试

测试 OpenStack 项目

项目通常有三类测试，提交必须通过这些测试才能准备进行审查

• 单元测试

每个项目内部自包含

• 风格检查

基于 flake8 和 hacking

• 集成测试

是 tempest 的一部分

单元测试

最重要的是，请参阅您正在使用的特定项目的文档。从其 HACKING.rst 文件开始，如果您在那里找不到足够的答案，请搜索。

以下是一些通用说明，如果项目的文档不够充分，可能会有所帮助。

有两种方法可以运行项目的单元测试：使用 tox，或使用项目的 run_tests.sh 脚本。使用 tox 是较新的约定，通常是首选；它还具有与 gate 执行相同的优势。

有两种常见的运行单元测试的环境：在由“git clone”产生的独立项目目录中，或在由 DevStack 创建的项目目录中。后者具有方便地用于集成测试以及单元测试的优势，但缺点是 DevStack 不保证不破坏您的工作；幸运的是，您可以在独立的项目目录中工作，并让 DevStack 使用该代码，而不是为该项目从主仓库克隆。

有些项目依赖于系统软件包 --- 也就是说，无法通过 pip 安装的软件包。在这种情况下，满足这些依赖关系的一般唯一方法是使用 DevStack 进行安装；项目的文档可能会说明其他方法。

使用 Tox 进行单元测试

建议您使用 pip [2] 安装 tox [1]。

[apt-get | yum] install python-pip

如果需要的话

pip install tox

示例 tox.ini 文件 https://github.com/openstack/nova/blob/master/tox.ini

每个项目根目录中都会有一个 tox.ini 文件。

在 tox.ini 文件中，您可能会看到以下任何 envlist 选项

[tox]	
envlist = py26,py27,py33,pep8,pylint

为了对其中一种环境运行 tox，您运行，例如

tox -e py27

大多数项目配置 tox 使用 testr 运行测试；请参阅 Testr。在这种情况下，如果您主要的运行环境合适，您可以使用 testr 在没有虚拟环境的情况下运行测试。

Tox 运行时间

为什么 tox 需要这么长时间才能运行？tox 需要很长时间的原因有两个：第一次运行它必须创建一个虚拟环境，这可能需要 5 到 30+ 分钟，具体取决于项目和系统。另一个原因是，运行某些项目的全部测试用例需要很长时间。

依赖失败

如果在运行 tox 时遇到依赖失败，请参阅您正在测试的项目的安装说明。这通常可以在项目树中的 doc/source/installation.rst 下找到，或在项目的页面上以 HTML 形式呈现 https://docs.openstack.org/developer/openstack-projects.html

run_tests.sh

存在较旧的约定，如下所示。大多数项目都有一个名为“run_tests.sh”的 shell 脚本，它运行该项目的单元测试。要调用它，只需“cd”到项目的目录并调用该脚本即可。例如，要在默认的 DevStack 安装中运行 Nova 单元测试，

cd /opt/stack/nova
./run_tests.sh

“run_tests.sh”脚本支持几个标志。您可以通过执行以下操作查看标志列表

run_tests.sh -h

“run_tests.sh”脚本通常是 (a) testr 或 nose 测试运行器和 (b) pep8 或 flake8 检查器的包装器。使用相关的 (a) 语法，您可以选择一部分测试。

风格检查

可以使用 `tox -epep8` 或手动使用 `flake8` 运行风格检查。

集成测试

手动集成测试

DevStack 产生一个正在运行的系统，所有进程都在 `screen` 下运行。然后

screen -r

将重新附加到该 screen 会话（如果它是唯一的）。您会发现为 DevStack 创建的每个 OpenStack 进程都有一个窗口。您可以回收其中一个进程，方法是杀死它 (^C) 并重新发出该窗口中的最后一个命令（您可以使用向上箭头来回忆）。

有两种方法可以使用 DevStack 对您正在进行更改的代码进行集成测试：直接方法和间接方法。在直接方法中，您在 DevStack 使用“git clone”创建的项目目录中进行更改。在间接方法中，您主要在单独的独立项目目录中进行更改，该目录使用“git clone”创建，并配置 DevStack 以从您的目录获取该项目的代码。后者建议使用，因为 DevStack 有时会丢弃本地更改。

直接方法

在直接方法中，您的 git 工作目录是 DevStack 通过“git clone”创建的那些目录之一，以创建工作系统，通常位于“/opt/stack”。例如，如果您正在对 Nova 进行更改，您的 git 工作目录将是“/opt/stack/nova”。您就地更改代码并回收相关的进程，顺序正确。您必须了解代码才能知道哪些是相关的进程以及正确的顺序。

间接方法

在间接方法中，您的主要 git 工作目录不是由 DevStack 创建的。例如，假设您正在使用 Nova 修复 bug 24601，并将使用 DevStack 安装到“/opt/stack”。您的主要 git 工作目录将位于其他位置，例如“~/code/nova”。您可能可以这样建立它（假设您已经完成了“git review -s”之前的 Gerrit 设置；请参阅 开发工作流程）。

mkdir ~/code
cd ~/code
git clone git://git.openstack.org/openstack/nova.git
cd nova
git review -s
git checkout -b bug/24601

然后，您将进行更改并将其提交到您刚刚创建的本地仓库，更新您的本地 master 分支（例如）。

之后，您使用 DevStack 创建一个正在运行的系统。为了让 DevStack 使用您的提交而不是 git.openstack.org 的 master 分支，您将您的 local.conf 文件（作为现代女性，您已经停止使用 localrc）覆盖相关的 REPO 和 BRANCH 变量。您可以在 DevStack 的 stackrc 脚本 中查看这些变量的默认值。例如，如果您的更改已提交到 /home/ubuntu/code/nova 的 master 分支，您会将以下内容放入您的 local.conf 中。

NOVA_REPO=/home/ubuntu/code/nova
NOVA_BRANCH=bug/24601

完成 DevStack 后，您将拥有一个正在运行的系统，该系统使用 Nova，如您在指定分支的本地工作目录（code/nova）中找到的那样。

当您需要进行进一步的更改时：在您的工作目录中进行更改，并将其提交到该本地仓库。然后使用 git 将它们拉到 DevStack 创建的目录

cd /opt/stack/nova
git pull

完成此操作后，像在直接方法中一样回收相关的进程。

自动化集成测试

请参阅 tempest。

运行 Swift 测试

Swift 具有可在源代码中 test 目录中找到的功能测试、功能 nose 测试和单元测试。