Python 测试的开放时代
由于主流 Python 测试框架的出现，上述的所有问题已经解决了，而且每种框架解决这些问题的方式大致相同。
首先，这三种测试框架都提供了从操作系统命令行运行测试的标准方法。这样，每个 Python 项目就不再需要在代码基中维护全局测试脚本。
zope.testing 包运行测试的机制是最特殊化的：因为 Zope 开发人员常常使用 buildout 设置他们的项目，常常通过 buildout.cfg 文件中的 zc.recipe.testrunner recipe 安装测试脚本。但是，结果在不同的项目上相当一致：在我遇到的每个 Zope 项目中，开发 buildout 都会创建一个 ./bin/test 脚本，可以通过它调用项目的测试。
py.test 和 nose 项目的做法更意思。它们都提供一个命令行工具，所以每个项目完全不需要有自己的测试命令：
# in the current directory...
$ py.test
# Run "nose" on the project
# in the current directory...
$ nosetests
py.test 和 nosetests 工具甚至有几个相同的命令行选项，比如 -v 选项在执行测试时输出测试的名称。可能过不了多久，只要程序员熟悉这两种工具，就能够运行大多数公共 Python 包的测试。
但是，还有最后一级标准化！当今的大多数 Python 项目在源代码中包含一个优异 setup.py 文件，它支持下面的命令：
$ python setup.py build
$ python setup.py install
当今的许多 Python 项目使用 setuptools 包支持标准 Python 没有提供的 setup.py 命令，包括运行项目的所有测试的 test 命令：
# then it will provide a "test" command too
$ python setup.py test
这是标准化的最高层次：如果项目都以一致的方式支持 setup.py test，开发人员就可以通过统一的接口运行所有 Python 包的测试套件。nose 通过提供一个入口点支持 setup.py，这个入口点调用与 nosetests 命令相同的测试运行例程：
from setuptools import setup
setup(
# ...
# package metadata
# ...
setup_requires = ['nose'],
test_suite = 'nose.collector',
)
当然，即使项目提供了 setup.py 入口点，大多数开发人员可能仍然使用 nosetests，因为 nosetests 提供更强大的命令行选项。但是对于新的开发人员，如果只想在调试 bug 或添加新特性之前检查包是否能够在他的平台上工作，那么 test_suite 入口点是非常方便的。
