Python 测试框架: 寻找要测试的模块

核心提示： 本系列的 第一篇文章 已经讨论过基于 TestCase 类的测试在现代环境中为什么常常是不必要的，但是，Python 测试框架: 寻找要测试的模块(2)，现在注意最后两行：它们起什么作用？答案是，它们检测什么时候从命令行单独运行这个 test_old.py 脚本，可以通过它调用项目的测试，

本系列的 第一篇文章 已经讨论过基于 TestCase 类的测试在现代环境中为什么常常是不必要的。但是，现在注意最后两行：它们起什么作用？答案是，它们检测什么时候从命令行单独运行这个 test_old.py 脚本，在这种情况下，它们运行一个 unittest 简便函数，这个函数在模块中搜索测试并运行它们。它们使这个测试文件可以独立于项目范围的测试脚本单独运行。

显然，在数十甚至数百个测试模块中复制相同的代码非常麻烦。另一个不太明显的缺点是这种做法不利于标准化。如果 test_main() 函数不够完善，无法检测出某个模块的测试，那么这个模块的行为可能与其他测试套件不匹配。因此，每个模块在测试类的名称、操作方式和运行方式方面稍有差异。

Python 测试的开放时代

由于主流 Python 测试框架的出现，上述的所有问题已经解决了，而且每种框架解决这些问题的方式大致相同。

首先，这三种测试框架都提供了从操作系统命令行运行测试的标准方法。这样，每个 Python 项目就不再需要在代码基中维护全局测试脚本。

zope.testing 包运行测试的机制是最特殊化的：因为 Zope 开发人员常常使用 buildout 设置他们的项目，常常通过 buildout.cfg 文件中的 zc.recipe.testrunner recipe 安装测试脚本。但是，结果在不同的项目上相当一致：在我遇到的每个 Zope 项目中，开发 buildout 都会创建一个 ./bin/test 脚本，可以通过它调用项目的测试。

py.test 和 nose 项目的做法更意思。它们都提供一个命令行工具，所以每个项目完全不需要有自己的测试命令：

#　Run　"py.test"　on　the　project　
#　in　the　current　directory...　
　
$　py.test　
　
#　Run　"nose"　on　the　project　
#　in　the　current　directory...　
　
$　nosetests