Python面向对象语言必须执行一些复杂的操作，比如在 Firefox 中打开网页并单击 “Continue” 按钮，然后检查结果。在开始实际测试（比如打开页面并单击按钮）之前，测试必须先完成一些步骤。
现在，考虑如果一百个功能性测试都要这样执行测试，会怎么样。它们都需要通过调用共同的 setup 例程运行 Firefox。然后才能执行自己的测试。与此相应，为了取消 setup 所做的操作，可能还有 teardown 代码。这样，在测试套件中就会增加两百个额外的函数调用。每个测试函数会像下面这样：
- # Naming a with_setup decorator
- firefox_test = with_setup(firefox_setup, firefox_teardown)
- @firefox_test
- def test_index_click():
- ...
- @firefox_test
- def test_index_menu():
- ...
为了消除这些重复的代码，许多测试框架提供了一次性指定每个测试都需要运行的 setup 和 teardown 代码的机制。本文讨论的三种框架 zope.testing、py.test 和 nose 都支持程序员编写的 unittest.TestCase 类中的标准 setUp() 和 tearDown() 例程。
但是，除此之外，Python面向对象语言各个框架为共同 setup 代码提供的特性有显著差异。zope.testing 本身没有为 setup 和 teardown 提供额外支持。但是前面讨论过的 z3c.testsetup 扩展会对 doctest 做一些有意思的处理。
它通过在文件中寻找 :Test-Layer: 字符串来寻找测试。doctest 中的层实际上可以指定两个值之一。如果把 doctest 标为属于 unit 层，就意味着运行它不需要任何特殊的 setup。但是，如果把它标为属于 functional 层，就意味着只能在调用框架 setup 函数之后运行它。
通常情况下，:Test-Layer: functional 测试被设计为在完整地配置了 Zope Web 框架的情况下运行。因此它们可以创建测试浏览器实例、发送请求和查看 Web 框架返回的响应。通过代表 doctest 执行 setup，z3c.testsetup 可以避免在每个功能性 doctest 中复制大量样板代码。
最后一项减少样板代码的便捷特性是，可以向 z3c.testsetup 提供一个预装载到每个单元 doctest 的名称空间中的变量列表。以及另一个预装载到每个功能性 doctest 中的变量列表。这样就不需要在每个 doctest 文件的开头复制一组相同的 import 语句。
Python面向对象语言 在默认情况下不提供对 setup 和 teardown 的支持。它甚至不运行标准 unittest.TestCase 类的 setUp() 和 tearDown() 方法，除非打开它的 unittest 插件。nose 在支持共同测试代码方面是最出色的。在寻找测试时，nose 跟踪记录找到测试的上下文。它认为 unittest.TestCase 子类内部的每个测试方法是这个类 “内部的”。
因此由它的 setUp() 和 tearDown() 方法控制，它还认为测试存在于它们的模块、包含模块的包以及外层所有包的 “内部”。因此，对于多层 “同心” 容器内的测试，nose 会在运行测试之前运行所有容器中的 setup 代码，在运行测试之后运行所有容器中的 teardown 代码。
最后，在 @with_setup 修饰符中指定的或作为 unittest.TestCase 子类中的方法提供的 setup 和 teardown 函数对于相关的每个函数或测试运行一次，而在模块级或包级向 nose 提供的 setup 和 teardown 代码对于整个测试集只运行一次。因此，不要认为这样的测试是完全互相隔离的：它们会共享在模块或包的 setup 例程中创建的资源拷贝。
【编辑推荐】
