Python 测试框架 选择和运行测试.docVIP

Python 测试框架 选择和运行测试 本文内容包括： Zope框架中的测试发现py.test和nose中的测试发现衍生测试(Generative tests)setup和teardown结束语参考资料 最近出现了行业级的Python测试框架，这意味着Python测试可以编写得更简洁、更统一，能够产生更好的结果报告。本文讨论三种最流行的测试框架如何识别和收集测试，以及它们如何支持编写完整的测试层，共享共同的setup和teardown代码。这三篇系列文章的第一篇文章讨论了标准测试框架(比如zope.testing、py.test和nose)给Python测试领域带来的革命性影响。这些框架支持更简单的测试方法，让项目不再需要为运行测试编写和维护专门的代码。第二篇文章讨论了这些自动化解决方案如何搜索Python包以识别可能包含测试的模块。 本文讨论下一步，介绍框架在找到测试模块之后如何发现其中的待测试项。还讨论一些细节，比如这三种框架对共同的setup和teardown代码的支持情况。 Zope框架中的测试发现 决定了感兴趣的模块列表之后，如何发现其中的实际测试呢? 对于zope.testing框架，您会发现Zope社区有一些有意思的现象。Zope社区并不为解决每个问题构建大型工具，而是构建小型的功能有限的工具，这些工具能够连接在一起。目前，zope.testing模块本身实际上根本没有提供检测测试的机制！ 相反，zope.testing让程序员自己寻找每个模块中需要运行的测试并把它们集中在一个列表中。它在每个测试模块中只寻找一个东西：test_suite()函数，这个函数应该返回标准unittest.TestSuite类的实例，其中包含模块定义的测试。 使用zope.testing的一些程序员在test_suite()函数中手工地创建和维护测试列表。其他程序员通过编写定制代码发现已经定义的可用测试。但是，最有意思的方法是使用另一个Zope包z3c.testsetup，它能够像其他现代Python测试框架一样自动地发现包中的测试。 这一现象再次说明Zope程序员倾向于编写小型代码块，然后使用它们构建框架，而不是编写大型的全面解决方案。z3c.testsetup包不包含可以选择测试的命令行界面，也不包含可以显示测试结果的输出模块；它完全依靠zope.testing实现这些功能。 实际上，z3c.testsetup用户一般不使用zope.testing的测试模块发现功能。相反，他们绕开zope.testing的算法，按照它的默认行为只寻找名为test.py的模块，然后在整个源代码树中只提供一个采用此名称的模块。在最简单的情况下，他们的test.py像下面这样： import z3c.testsetup test_suite=z3c.testsetup.register_all_tests(my_package) 这完全不通过zope.testing执行测试发现任务，而是依靠z3c.testsetup本身提供的更强大的发现机制。 可以向register_all_tests()函数提供几个配置选项。详细信息请参见z3c.testsetup文档，这里只需要介绍它的基本行为。与本文讨论的其他框架不同，z3c.testsetup在默认情况下不关心包中每个Python模块的名称，而是关注它的内容。它检查所有模块以及包中的所有.txt或.rst文件，选择文本中指定了：Test-Layer：的文件。然后，它组合模块中的所有TestCase和文本文件中的所有doctest部分，形成测试套件。 使用：Test-Layer：字符串标出包含测试的文件是一种有意思的机制。它的缺点是，在浏览包的文件时，为了找到测试的位置，新程序员必须打开每个文件，至少要用grep命令寻找：Test-Layer：字符串。(更不用提z3c.testsetup显然必须做同样的事；这使它比那些只操作文件名的框架要慢)。 最后注意，Zope测试框架只支持UnitTest实例或doctest。正如本系列的第一篇文章中讨论的，更现代的Python测试框架还支持一般的Python函数作为有效测试。这需要不同的测试检测算法，在下面讨论的框架中就会看到。 py.test和nose中的测试发现 正如前一篇文章中提到的，py.test和nose框架使用相似但略有差异的规则集搜索Python包，寻找它们认为包含测试的模块。但是，之后它们都会遇到相同的情况：它们必须检查模块列表，寻找开发人员希望作为测试运行的函数和类。 正如在前一篇文章中看到的，py.test往往选择单一标准，期望使用它的所有项目都遵守这一标准；而nose允许更丰富的定制，但是这会牺牲行为的可预测性。对于测试发现，也是如此：py.test