深度剖析Python面向?qū)ο笳Z言內(nèi)容
Python面向?qū)ο笳Z言必須執(zhí)行一些復雜的操作，比如在 Firefox 中打開網(wǎng)頁并單擊 “Continue” 按鈕，然后檢查結(jié)果。在開始實際測試（比如打開頁面并單擊按鈕）之前，測試必須先完成一些步驟。
現(xiàn)在，考慮如果一百個功能性測試都要這樣執(zhí)行測試，會怎么樣。它們都需要通過調(diào)用共同的 setup 例程運行 Firefox。然后才能執(zhí)行自己的測試。與此相應，為了取消 setup 所做的操作，可能還有 teardown 代碼。這樣，在測試套件中就會增加兩百個額外的函數(shù)調(diào)用。每個測試函數(shù)會像下面這樣：
- # 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面向?qū)ο笳Z言各個框架為共同 setup 代碼提供的特性有顯著差異。zope.testing 本身沒有為 setup 和 teardown 提供額外支持。但是前面討論過的 z3c.testsetup 擴展會對 doctest 做一些有意思的處理。
它通過在文件中尋找 :Test-Layer: 字符串來尋找測試。doctest 中的層實際上可以指定兩個值之一。如果把 doctest 標為屬于 unit 層，就意味著運行它不需要任何特殊的 setup。但是，如果把它標為屬于 functional 層，就意味著只能在調(diào)用框架 setup 函數(shù)之后運行它。
通常情況下，:Test-Layer: functional 測試被設計為在完整地配置了 Zope Web 框架的情況下運行。因此它們可以創(chuàng)建測試瀏覽器實例、發(fā)送請求和查看 Web 框架返回的響應。通過代表 doctest 執(zhí)行 setup，z3c.testsetup 可以避免在每個功能性 doctest 中復制大量樣板代碼。
最后一項減少樣板代碼的便捷特性是，可以向 z3c.testsetup 提供一個預裝載到每個單元 doctest 的名稱空間中的變量列表。以及另一個預裝載到每個功能性 doctest 中的變量列表。這樣就不需要在每個 doctest 文件的開頭復制一組相同的 import 語句。
Python面向?qū)ο笳Z言 在默認情況下不提供對 setup 和 teardown 的支持。它甚至不運行標準 unittest.TestCase 類的 setUp() 和 tearDown() 方法，除非打開它的 unittest 插件。nose 在支持共同測試代碼方面是最出色的。在尋找測試時，nose 跟蹤記錄找到測試的上下文。它認為 unittest.TestCase 子類內(nèi)部的每個測試方法是這個類 “內(nèi)部的”。
因此由它的 setUp() 和 tearDown() 方法控制，它還認為測試存在于它們的模塊、包含模塊的包以及外層所有包的 “內(nèi)部”。因此，對于多層 “同心” 容器內(nèi)的測試，nose 會在運行測試之前運行所有容器中的 setup 代碼，在運行測試之后運行所有容器中的 teardown 代碼。
最后，在 @with_setup 修飾符中指定的或作為 unittest.TestCase 子類中的方法提供的 setup 和 teardown 函數(shù)對于相關的每個函數(shù)或測試運行一次，而在模塊級或包級向 nose 提供的 setup 和 teardown 代碼對于整個測試集只運行一次。因此，不要認為這樣的測試是完全互相隔離的：它們會共享在模塊或包的 setup 例程中創(chuàng)建的資源拷貝。
【編輯推薦】
