Python 高手编程系列三百八十四：测试环境与依赖兼容性

环境隔离的重要性在本书中已经提到很多次了。通过在应用程序级（虚拟环境）和系
统级（系统虚拟化）上隔离执行环境，你可以确保测试可以在可重复的条件下运行。这样，
你可以避免受因破坏依赖关系导致的罕见且模糊的问题。
正确隔离测试环境的最佳方法是使用支持系统虚拟化的持续集成系统。对于开源项目
有很好的免费解决方案，如 Travis CI（Linux 和 OS X）或 AppVeyor（Windows），但是如
果你需要这样的东西来测试私有的软件，很可能你需要花一些时间，在一些现有的开源 CI
工具（GitLab CI、Jenkins 和 Buildbot）之上，自己构建这样的解决方案。
依赖矩阵测试
大多数情况下，开源 Python 项目的测试矩阵主要关注不同的 Python 版本，很少关注
不同的操作系统。对于纯 Python 并且没有与操作系统互相操作问题的项目，没有必要在不
同的系统上进行测试和构建。但是有一些项目，特别是作为编译的 Python 扩展分发时，应
该在各种目标操作系统上进行测试。对于开源项目，甚至不得不使用几个独立的 CI 系统进
行构建，用来适配 3 种最流行的操作系统（Windows、Linux 和 Mac OS X）。如果你正在寻
找一个很好的例子，你可以看一下这个小 pyrilla 项目（参考 https://github.com/swistakm/
pyrilla），这是一个简单的 C 音频 Python 扩展。它同时使用 Travis CI 和 AppVeyor，目的是
为了提供 Windows 和 Mac OS X 的编译版本以及大范围的 CPython 版本。
但是测试矩阵的维度不会局限在系统和 Python 版本上。提供与其他软件（如缓存、数
据库或系统服务）集成的软件包通常应在各种版本的集成应用程序上进行测试。tox（参考
http://tox.readthedocs.org）是一个好工具，可以使这样的测试更加容易。它提供了一种简单的方法来配置多个测试环境并使用一个 tox 命令运行所有测试。它是一个非常强大和灵活
的工具，并且也很容易使用。展示它的用法的最好的方式是给你一个配置文件的例子，其
实它就是 tox 的核心。这里有一个 tox.ini 文件，它来自 django-userena 项目（参考 https://
github.com/bread-andpepper/django-userena）：
[tox]
downloadcache = {toxworkdir}/cache/
envlist =
; py26 support was dropped in django1.7
py26-django{15,16},
; py27 still has the widest django support
py27-django{15,16,17,18,19},
; py32, py33 support was officially introduced in django1.5
; py32, py33 support was dropped in django1.9
py32-django{15,16,17,18},
py33-django{15,16,17,18},
; py34 support was officially introduced in django1.7
py34-django{17,18,19}
; py35 support was officially introduced in django1.8
py35-django{18,19}
[testenv]
usedevelop = True
deps =
django{15,16}: south
django{15,16}: django-guardian<1.4.0
django15: django1.5.12
django16: django1.6.11
django17: django1.7.11
django18: django1.8.7
django19: django1.9
coverage: django1.9
coverage: coverage4.0.3
coverage: coveralls1.1
basepython =
py35: python3.5
py34: python3.4
py33: python3.3
py32: python3.2
py27: python2.7
py26: python2.6
commands={envpython} userena/runtests/runtests.py userenaumessages
{posargs}
[testenv:coverage]
basepython = python2.7
passenv = TRAVIS TRAVIS_JOB_ID TRAVIS_BRANCH
commands=
coverage run --source=userena userena/runtests/runtests.py
userenaumessages {posargs}
coveralls
这个配置允许你在 5 个不同版本的 Django 和 6 个版本的 Python 上测试 django-userena
项目。并不是每个 Django 版本都可以在每个 Python 版本上工作，tox.ini 文件使得定义
这样的依赖性约束相对容易。在实践中，整个构建矩阵包括 21 个唯一的环境（包括用于代
码覆盖收集的特殊环境）。手动创建每个测试环境需要付出很多努力，即使使用 shell 脚本
也不太容易。
Tox 是很棒，但如果我们想改变测试环境中其他一些不是纯 Python 依赖的元素，它的
使用会变得很复杂。有这样一种情况，当我们需要在不同版本的系统包和支持服务上测试
时。解决这个问题的最好方法是再次使用良好的持续集成系统，这可以使你能够轻松地定
义环境变量的矩阵并在虚拟机上安装系统软件。使用 Travis CI 的一个很好的例子是 ianitor
项目（参考 https://github.com/ClearcodeHQ/ianitor/），在第 9 章，文档化你的项目中已经提
到过它。这是一个简单的实用程序，用于 Consul 服务发现。Consul 项目拥有一个非常活跃
的社区，每年都会发布很多版本。对该服务的各种版本进行测试是很有必要的。这确保
ianitor 项目仍然是该软件的最新版本，并且也不会破坏与以前的 Consul 版本的兼容性。以
下是 Travis CI 的.travis.yml 配置文件的内容，它允许你针对 3 个不同的 Consul 版本和
4 个 Python 解释器版本进行测试如下所示：
language: python
install: pip install tox --use-mirrors
env:
matrix:

consul 0.4.1

• TOX_ENV=py27 CONSUL_VERSION=0.4.1
• TOX_ENV=py33 CONSUL_VERSION=0.4.1
• TOX_ENV=py34 CONSUL_VERSION=0.4.1
• TOX_ENV=py35 CONSUL_VERSION=0.4.1

• consul 0.5.2

• TOX_ENV=py27 CONSUL_VERSION=0.5.2
• TOX_ENV=py33 CONSUL_VERSION=0.5.2
• TOX_ENV=py34 CONSUL_VERSION=0.5.2
• TOX_ENV=py35 CONSUL_VERSION=0.5.2

consul 0.6.4

• TOX_ENV=py27 CONSUL_VERSION=0.6.4
• TOX_ENV=py33 CONSUL_VERSION=0.6.4
• TOX_ENV=py34 CONSUL_VERSION=0.6.4
• TOX_ENV=py35 CONSUL_VERSION=0.6.4

coverage and style checks

• TOX_ENV=pep8 CONSUL_VERSION=0.4.1
• TOX_ENV=coverage CONSUL_VERSION=0.4.1
  before_script:
• wget https://releases.hashicorp.com/consul/KaTeX parse error: Expected group after '_' at position 25: …ERSION}/ consul_̲{CONSUL_VERSION}_linux_amd64.zip
• unzip consul_${CONSUL_VERSION}_linux_amd64.zip
• start-stop-daemon --start --background --exec pwd/consul –
  agent -server -data-dir /tmp/consul -bootstrap-expect=1
  script:
• tox -e $TOX_ENV
  前面的示例为 ianitor 代码提供了 14 个唯一的测试环境（包括 pep8 和 coverage 构
  建）。此配置还使用 tox 在 Travis VM 上创建实际测试虚拟环境。实际上，这是一个非常流
  行的方法，用于 tox 与不同的 CI 系统的整合。通过将更多的测试环境配置迁移到 tox 中，
  你可以降低将自己锁定到单个供应商的风险。诸如安装新服务或定义系统环境变量的事情，
  大多数 Travis CI 竞争对手都支持，因此如果市场上有更好的产品，或者 Travis 改变对开源
  项目的定价模型，你可以很容易地切换到其他的服务提供商。