测试 Ansible
为什么测试您的 Ansible 贡献？
如果您是开发者，您可以做最有价值的事情之一就是查看 GitHub 问题并帮助修复错误，因为修复错误几乎总是优先于功能开发。即使对于非开发者，帮助测试拉取请求以修复错误和功能也仍然非常有价值。
了解如何编写剧本和角色的 Ansible 用户应该能够测试他们的工作。GitHub 拉取请求将自动运行各种测试（例如，Azure Pipelines），这些测试会显示实际运行中的错误。但是，贡献者还必须在自动化的 GitHub 检查之外测试他们的工作，并在拉取请求中显示这些测试的证据，以确保他们的工作更有可能被审查和合并。
继续阅读以了解如何测试 Ansible，如何在本地测试您的贡献以及如何扩展测试功能。
如果您想了解有关测试集合的信息，请阅读 测试集合
测试类型
在高层次上，我们对测试有以下分类
在 GitHub 和 Azure Pipelines 中进行测试
组织
创建拉取请求 (PR) 时，将使用 Azure Pipelines（一种持续集成 (CI) 工具）对其进行测试。结果将在每个 PR 的末尾显示。
当 Azure Pipelines 检测到错误并且可以将其链接回 PR 中修改的文件时，相关的行将作为 GitHub 评论添加。例如
The test `ansible-test sanity --test pep8` failed with the following errors:
lib/ansible/modules/network/foo/bar.py:509:17: E265 block comment should start with '# '
The test `ansible-test sanity --test validate-modules` failed with the following error:
lib/ansible/modules/network/foo/bar.py:0:0: E307 version_added should be 2.4. Currently 2.3
从上面的例子中我们可以看到 --test pep8 和 --test validate-modules 已经识别到一个问题。给出的命令允许您在本地运行相同的测试，以确保您已经修复了所有问题，而无需将更改推送到 GitHub 并等待 Azure Pipelines，例如
如果您还没有安装 Ansible，请使用本地检出运行
source hacking/env-setup
然后运行 GitHub 评论中详细说明的测试
ansible-test sanity --test pep8
ansible-test sanity --test validate-modules
如果没有 GitHub 评论说明失败的原因，您可以通过点击 PR 末尾“检查失败”消息下的“详细信息”按钮来检查结果。
重新运行失败的 CI 作业
偶尔您可能会发现您的 PR 失败，原因与您的更改无关。这可能由于以下几个原因造成：
暂时无法访问外部资源，例如 yum 或 git 仓库
创建虚拟机以运行测试时超时
如果出现上述任一问题，您可以通过以下方式重新运行 Azure Pipelines 测试：
在拉取请求中添加带有
/rebuild（完全重建）或/rebuild_failed（仅重建失败的 CI 节点）的评论关闭并重新打开拉取请求（完全重建）
对分支进行其他更改并推送到 GitHub
如果问题仍然存在，请在 #ansible-devel 聊天频道中与我们联系（使用 Matrix 或使用 irc.libera.chat 上的 IRC）。
如何测试 PR
理想情况下，代码应该添加测试来证明代码有效。这并不总是可能的，而且测试也不总是全面的，尤其是在用户没有访问各种平台或使用 API 或 Web 服务时。在这些情况下，针对真实设备进行现场测试可能比针对模拟接口运行的自动化测试更有价值。无论如何，所有内容都应该在第一次手动测试。
值得庆幸的是，帮助测试 Ansible 相当简单，假设您熟悉 Ansible 的工作原理。
设置：安装 Pytest 和所需的 Pytest 库
Ansible 的单元测试框架利用了 pytest 库。在深入测试之前，请确保您安装了 pytest 以及任何其他 pytest 库，例如 pytest-mock 和 pytest-xdist。
有关更多信息，请参阅文档：单元测试。
设置：检出拉取请求
您可以通过以下方式完成此操作：
检出 Ansible
将建议的更改提取到测试分支
测试
在 GitHub 上对此特定问题进行评论
以下是方法：
警告
测试从 GitHub 拉取请求发送给我们的源代码确实存在一些固有风险，因为发送的源代码可能存在错误或恶意代码，这些代码可能会对您的系统产生负面影响。我们建议您在虚拟机上进行所有测试，无论是云实例还是本地实例。一些用户喜欢使用 Vagrant 或 Docker 来完成此操作，但它们是可选的。拥有不同 Linux 或其他版本的虚拟机也很有用，因为某些功能（例如，apt 或 yum 等软件包管理器）特定于这些操作系统版本。
创建一个新的工作区
git clone https://github.com/ansible/ansible.git ansible-pr-testing
cd ansible-pr-testing
接下来，找到您要测试的拉取请求并记下它的编号。它看起来像这样
Use os.path.sep instead of hardcoding / #65381
注意
只测试 ansible:devel
重要的是 PR 请求目标为 ansible:devel，因为我们不接受任何其他分支的拉取请求。点版本由 Ansible 员工手动 cherry-pick。
在提取建议的更改并创建测试分支时，使用拉取请求编号
git fetch origin refs/pull/XXXX/head:testing_PRXXXX
git checkout testing_PRXXXX
第一个命令从拉取请求中提取建议的更改，并创建一个名为 testing_PRXXXX 的新分支，其中 XXXX 是与拉取请求关联的实际数字（例如，65381）。第二个命令检出新创建的分支。
注意
如果 GitHub 用户界面显示拉取请求无法干净地合并，我们建议如果您不熟悉 git 和编码，不要继续，因为您将不得不解决合并冲突。这是原始拉取请求贡献者的责任。
注意
有些用户不创建功能分支，这会导致他们在其 devel 版本中有多个无关的提交时出现问题。如果源代码看起来像 someuser:devel，请确保拉取请求中只列出了一个提交。
Ansible 源代码包含一个脚本，允许您直接从源代码使用 Ansible，而无需完整安装，这经常被 Ansible 的开发人员使用。
只需将其作为源代码（使用 Linux/Unix 术语）即可立即开始使用。
source ./hacking/env-setup
此脚本会修改 PYTHONPATH 环境变量（以及其他一些内容），只要您的 shell 会话保持打开状态，这些变量就会被暂时设置。
测试拉取请求
此时，您应该已经准备好开始测试了！
以下是一些测试想法：
使用示例创建测试剧本，并检查它们是否正常工作。
测试是否返回了任何 Python 回溯（这表明存在错误）。
在不同的操作系统上进行测试，或针对不同的库版本进行测试。
运行完整性测试
ansible-test sanity
更多信息：完整性测试
运行单元测试
ansible-test units
更多信息：单元测试
运行集成测试
ansible-test integration -v ping
更多信息：集成测试
任何潜在问题都应作为注释添加到拉取请求中（如果该功能正常工作，也可以添加注释），请记住包括 ansible --version 的输出。
示例
Works for me! Tested on `Ansible 2.3.0`. I verified this on CentOS 6.5 and also Ubuntu 14.04.
如果 PR 没有解决问题，或者您看到单元/集成测试出现任何失败，只需包含该输出。
此更改导致我出现错误。我在 Ubuntu 16.04 上运行它时，出现了以下错误：```一些输出堆栈跟踪其他一些输出```
代码覆盖率在线
在线代码覆盖率报告 是识别 Ansible 中测试改进领域的有效方法。通过关注红色部分，您可以深入研究报告以查找完全没有测试的文件。添加集成测试和单元测试，以清晰地展示代码应该如何工作、验证重要的 Ansible 功能并增加没有测试覆盖率的区域的测试覆盖率，是帮助改进 Ansible 的有价值的方式。
代码覆盖率报告仅涵盖 Ansible 的 devel 分支，该分支进行新的功能开发。拉取请求和新代码将不会出现在 codecov.io 覆盖率报告中，因此需要本地报告。大多数 ansible-test 命令允许您收集代码覆盖率，这对于指示在哪里扩展测试特别有用。有关更多信息，请参阅 测试 Ansible 和集合。
想要了解更多关于测试的信息？
如果您想了解有关改进 Ansible 测试计划的更多信息，为什么不加入 Ansible 社区论坛 呢？