浅谈Python任务自动化工具Tox
引言：
最近在搜集github上包含测试样例的Python项目，并试图在docker环境下跑通这些项目，发现这些项目主要使用的测试框架有 ： unittest, pytest ,nosetest。还有一些用到了自动化工具Tox，所以简单了解了一下。
简介：
Command line driven CI frontend and development task automation tool
命令行驱动的 CI 前端和开发任务自动化工具
其核心作用是支持创建隔离的 Python 环境，在里面可以安装不同版本的 Python 解释器与各种依赖库，以此方便开发者做自动化测试、打包、持续集成等事情。
创建开发环境
运行静态代码分析与测试工具
自动化构建包
针对 tox 构建的软件包运行测试
检查软件包是否能在不同的 Python 版本/解释器中顺利安装
统一持续集成（CI）和基于命令行的测试
创建和部署项目文档
将软件包发布到 PyPI 或任何其它平台简单来说，tox 是一个管理测试虚拟环境的命令行工具。 它已存在多年且广被开发者们使用，例如，著名的云计算平台 OpenStack 也采用了它，作为最基础的测试工具之一。
基本用法：
安装
pip install tox将有关项目和希望项目在其中运行的测试环境的基本信息放入应位于文件旁边的文件中：tox.ini setup.py
# content of: tox.ini , put in same dir as setup.py
[tox]
envlist = py27,py36
[testenv]
# install testing framework
# ... or install anything else you might need here
deps = pytest
# run the tests
# ... or run any other command line tool you need to run here
commands = pytest若要打包、安装和测试项目，现在可以在命令提示符下键入：
tox配置文件：
tox 的行为由其配置文件控制，当前它支持 3 种配置文件：
pyproject.tomltox.inisetup.cfg
我们以**python-project-wizard**项目为例，看一下开发人员写的tox配置文件。
pyproject.toml
[tool]
[tool.poetry]
name = "ppw"
version = "1.1.1"
description = "A Wizard to create a skeleton python project with up-to-date technology"
license = "BSD-3-Clause"
authors = ["Aaron Yang <aaron_yang@jieyu.ai>"]
readme = "README.md"
repository = "https://github.com/zillionare/cookiecutter-pypackage"
documentation = "https://zillionare.github.io/cookiecutter-pypackage/"
keywords = ['cookiecutter', 'template', 'package']
packages = [
{include = "ppw"}
]
include = [
'{{cookiecutter.project_slug}}/**/*',
'cookiecutter.json',
'hooks/*'
]
[tool.poetry.dependencies]
python = ">=3.7,<4.0"
cookiecutter = "1.7.2"
pytest = {version = "^5.4.3", optional=true}
pytest-cookies = {version = "^0.5.1", optional=true}
pyyaml = {version="^5.3.1",optional=true}
mkdocs = {version="^1.1.2",optional=true}
mkdocs-material = {version="^6.1.7",optional=true}
mkdocs-material-extensions = {version="^1.0.1",optional=true}
pytest-cov = {version="^2.10.1",optional=true}
tox = {version = "^3.20.1", optional=true}
mkdocs-include-markdown-plugin = {version = "^2.8.0", optional=true}
fire = {version="^0.4.0", optional=true}
pre-commit = {version="^2.18.1",optional=true}
[tool.poetry.extras]
dev = [
"pytest",
"pytest-cookies",
"pyyaml",
"mkdocs",
"mkdocs-material",
"mkdocs-material-extensions",
"pytest-cov",
"tox",
"mkdocs-include-markdown-plugin",
"fire"
]
[tool.black]
line-length = 88
include = '\.pyi?$'
exclude = '''
/(
\.eggs
| \.git
| \.hg
| \.mypy_cache
| \.tox
| \.venv
| _build
| buck-out
| build
| dist
)/
'''
[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"
[tool.poetry.scripts]
ppw = 'ppw.cli:main'- INI（
.ini）文件是一种非常原始的基础形式，但各家有各家的用法，而且它最多只能解决一层嵌套。只适合非常非常简单的配置文件，一旦需要两层嵌套，或需要数组，就力不从心了。 - 终于，TOML（
.toml）横空出世。它彻底放弃了括号或缩进的底层原理，而是采取了显式键名链的方式。
tox.ini
[tox]
envlist = py37,py38,py39,py310, docs
isolated_build = True
[gh-actions]
python =
3.7: py37
3.8: py38, docs
3.9: py39
3.10: py310
[testenv:docs]
basepython=python
allowlist_externals = mkdocs
commands= mkdocs build
[testenv]
extras =
dev
setenv =
PYTHONPATH = {toxinidir}
commands = pytest -s --cov-report=term-missing tests- 每个[xxx]及其下方内容组成一个章节（section），每个章节间使用空行作间隔。
- [tox]下面是全局性的配置项
- [xxx:yyy]继承 xxx 的配置，同时其自身配置项的优先级更高。
- 对于每个虚拟环境，可用的配置项很多，例如常用的有：description（描述信息）、basepython（Python解释器版本）、deps（环境依赖项）、commands（命令语句）等等。
tox 的工作流程:
- 配置（从figuration）：加载配置文件（如 tox.ini），解析命令行参数，读取系统环境变量等
- 打包（packaging）：可选的，对于带有 setup.py 文件的项目，可以在这步去生成它的源发行版
- 创建虚拟环境：默认使用 virtualenv 来创建虚拟环境，并根据配置项中的“deps”安装所需的依赖项，然后执行配置好的命令（commands）
- 报告（report）：汇总所有虚拟环境的运行结果并罗列出来
安装使用：
安装：
使用tox-quickstart快速生成tox.ini，也可以根据模板手写tox.ini文件
使用：
- 配置好文件后，可以tox 直接运行，也可以tox -e test_api
- 如果在其他目录下运行，则需要tox -c /test/tox.ini -c是指定配置文件的意思
小结：
tox 本身定位是一个测试工具，它试图令 Python 测试工作变得自动化、标准化与流程化。但跟 unittest 和 pytest 这些测试框架不同，它作用的是代码层面之外的事情，是一种项目级的工具。因此，它需要跟这些测试框架相结合，或者同时处理多种自动化任务（如跑 pep8、测代码覆盖率、生成文档等等），这样才能更好地发挥它的价值。
它的一大特色在于创建/管理虚拟环境，但这只是为了方便测试而使用的手段，因此相比其它可管理虚拟环境的工具，如 Virtualenvwrapper、conda、pipenv、poetry，它在某些方面就存在着不足。
