【正文】 // Verify OuteassertExactly2FlightsInDtoList( Flights at origin,outboundFlights, flightsAtOrigin)。 }為了讓使用標準夾具更加明顯，該示例通過調(diào)用相同的創(chuàng)建方法來建立標準夾具(例如，使用委托建立)，顯示每個測試中顯式創(chuàng)建的新鮮夾具。將夾具構(gòu)造邏輯放置到setUp方法中，也可以實現(xiàn)相同效果，實際上也就是使用隱式建立。結(jié)果測試與使用共享夾具的測試看起來一樣。 新鮮夾具(也稱為新鮮上下文、私有夾具) 應(yīng)該使用哪種夾具策略？各測試為了自己的私有用法而構(gòu)造各自全新的測試夾具。圖187 新鮮夾具示意圖所有測試都需要測試夾具，它在測試前定義測試環(huán)境的狀態(tài)。每次運行測試時都重新構(gòu)建夾具還是重用以前構(gòu)建的夾具，這是一個重要的測試自動化決定。當每個測試都創(chuàng)建新鮮夾具時，不穩(wěn)定測試就會很少，測試努力也很可能產(chǎn)生作為文檔的測試。 運行原理設(shè)計和構(gòu)建測試夾具，以便只有單個測試的單次運行會使用它。作為運行測試的一部分構(gòu)造夾具，測試完成后拆卸夾具。不再重復(fù)使用其他測試或其他測試運行遺留下來的任何夾具。這樣，每個測試的開始和結(jié)束都具有“清白歷史”。 使用時機要避免可能導(dǎo)致不穩(wěn)定測試的測試之間的相互依賴，例如單獨測試(參見“不穩(wěn)定測試”)或交互測試(參見“不穩(wěn)定測試”)，我們應(yīng)該使用新鮮夾具。如果因為新鮮夾具極大地減緩測試而不使用它，那么在求助共享夾具之前應(yīng)該考慮使用不可變的共享夾具(參閱“共享夾具”)。注意，使用數(shù)據(jù)庫分區(qū)方案(參見“數(shù)據(jù)庫沙盒”)為其他測試不會接觸到的測試創(chuàng)建私有數(shù)據(jù)庫沙盒，這樣不會產(chǎn)生新鮮夾具，因為后面的測試運行會使用相同的夾具。 實現(xiàn)方式說明如果打算單次使用夾具，那么就可以認為它是新鮮夾具。新鮮夾具是暫時的還是永久的，取決于SUT的性質(zhì)以及寫測試的方法(如圖188所示)。意圖相同時，如果新鮮夾具是永久夾具，實現(xiàn)方式考慮因素在某種程度上有所不同。夾具建立基本上不受影響，因此它可以作為所有類似夾具的公共特征討論。夾具拆卸專用于特定變體。圖188 測試夾具策略。根據(jù)在測試中是暫時或永久的，夾具可以是新鮮的、共享的或兩者的結(jié)合(不可變的共享夾具) 保留夾具的原因由于下面兩種原因，構(gòu)造的夾具在測試方法完成之后可以保留下來。第一，如果夾具主要由SUT依賴的其他對象或組件的狀態(tài)組成，其永久性由這些對象本身是不是永久對象確定。數(shù)據(jù)庫就是這種示例之一。這是因為只要有些代碼將夾具對象保留到數(shù)據(jù)庫，對象就會在測試完成后長時間“保留”，它們在數(shù)據(jù)庫中就會導(dǎo)致我們自己的測試(不可重復(fù)的測試；參見“不穩(wěn)定測試”)多個運行之間的沖突。其他測試也能夠訪問這些對象，這會導(dǎo)致其他形式的不穩(wěn)定測試，例如交互測試和測試運行沖突。如果必須使用數(shù)據(jù)庫或其他形式的對象永久性，應(yīng)該采取其他措施讓夾具保持私有。另外，每個測試方法完成之后應(yīng)該拆卸夾具。夾具可能永久的第二個原因在于測試的控件，也就是說，選擇哪種類型的變量來保存對夾具的引用。測試方法完成執(zhí)行后，局部變量自然會超出范圍，因此無用單元收集會銷毀所有保存在局部變量里的夾具。測試用例對象被破壞后，實例變量就會超出范圍8 xUnit家族的大多數(shù)成員都為每個測試方法創(chuàng)建單獨的測試用例對象。然而，有一些不這樣做。當粗心的測試自動化人員首次使用家族的這些成員時，這種差別可能會妨礙他們，因為實例變量可能非常類似類變量。該問題的詳細描述，請參見“總是有異?！辈糠謨?nèi)容。，如果xUnit架構(gòu)在各測試運行過程中沒有再創(chuàng)建測試用例對象，同時還需要顯式拆卸。相反，類變量通常導(dǎo)致永久夾具，這些夾具存在的時間比單個測試方法甚至是測試運行的時間還要長，所以使用新鮮夾具時要避免使用它們。實際上，夾具在單元測試中通常不是永久性的9 “單元測試標準”部分說明了單元測試的構(gòu)成。，除非將應(yīng)用程序邏輯與數(shù)據(jù)庫緊密聯(lián)系在一起。寫客戶測試或組件測試時，夾具很可能是永久性的。 新鮮夾具建立夾具是永久的還是暫時的不影響夾具的構(gòu)造。需要考慮的主要是建立夾具的代碼位置。如果夾具建立相對簡單，可以使用內(nèi)聯(lián)建立。對于更復(fù)雜的夾具，當使用每個類一個測試用例類或每種特征一個測試用例類來組織測試方法時，通常使用委托建立。如果使用每個夾具一個測試用例類組織方法，就可以使用隱式建立來構(gòu)建夾具。1. 變體：暫時新鮮夾具如果需要從測試的幾個位置引用夾具，就應(yīng)該只使用局部變量或?qū)嵗兞縼硪脢A具。大多數(shù)情況下，不用努力就可以依賴無用單元收集拆卸來銷毀夾具。注意，如果在運行每個測試方法之前重新構(gòu)建夾具，那么標準夾具也可能是新鮮夾具。這種方法重復(fù)使用夾具的設(shè)計而不是實例。使用隱式建立但不使用每個夾具一個測試用例類來組織測試方法時，通常會遇到這種情況。2. 變體：永久新鮮夾具如果使用永久新鮮夾具，那么需要拆卸夾具，或者采取特殊措施避免拆卸。使用內(nèi)聯(lián)拆卸、隱式拆卸、委托拆卸(參見“內(nèi)聯(lián)拆卸”)或自動拆卸將測試環(huán)境保持在進入時的狀態(tài)，這樣可以拆卸夾具。要避免夾具拆卸，可以為每個獨特的夾具對象使用不同生成值(參見“生成值”)。這種策略可以成為數(shù)據(jù)庫分區(qū)方案的基礎(chǔ)，該方案試圖將測試和測試運行器彼此分開。萬一拆卸過程失敗，它也可以防止資源泄漏(參見“不穩(wěn)定測試”)。還可以將這種方法與某種拆卸模式結(jié)合起來，雙重確保不存在不可重復(fù)的測試或交互測試。這種額外運行有一些不足，這并不奇怪：它讓測試寫起來更復(fù)雜，而且通常會導(dǎo)致緩慢測試。正常反應(yīng)是通過在許多測試中重用它來利用夾具的永久性，以此避免建立和拆卸它的系統(tǒng)開銷。遺憾的是，這種選擇有許多不受歡迎的結(jié)果，因為它違背了一條主要原則：保持測試獨立。作為結(jié)果的共享測試不可避免地導(dǎo)致交互測試和不可重復(fù)的測試，不是現(xiàn)在，就是以后的某個時候。在沒有完全了解后果的情況下不應(yīng)該冒這個險！ 啟發(fā)示例下面是共享夾具的示例：static Flight flight。 public void setUp() {if (flight == null) { // Lazy SetUpAirport departAirport = new Airport(Calgary, YYC)。 Airport destAirport = new Airport(Toronto, YYZ)。 flight = new Flight( flightNumber,departAirport, destAirport)。 } }public void testGetStatus_inital_S() {// implicit setup// exercise SUT and verify outeassertEquals(, ())。// teardown }public void testGetStatus_cancelled() {// implicit setup partially overridden()。// exercise SUT and verify outeassertEquals(, ())。// teardown}從這里顯示的實際建立夾具的代碼來看，它是正常的共享夾具，但在這個啟發(fā)示例中使用了預(yù)制夾具。無論哪種方法，這些測試隨時都可以開始交互。 重構(gòu)說明假設(shè)使用共享夾具(相同設(shè)計、單個副本)，并決定將它重構(gòu)使用新鮮夾具。首先可以重構(gòu)測試讓它使用新鮮的標準夾具(相同設(shè)計、多個副本)。接著可以決定是否需要使用最小化數(shù)據(jù)重構(gòu)將夾具建立邏輯簡化為最簡形式，以此進一步發(fā)展測試，讓它構(gòu)建最小夾具。此時也是將需要相同類型測試夾具的測試方法分組為每個夾具一個測試用例類和使用隱式建立的好時機，使用標準夾具可以減少需要設(shè)計和構(gòu)建的最小夾具的數(shù)量。 示例：新鮮夾具下面是轉(zhuǎn)換為新鮮夾具以避免產(chǎn)生交互測試的相同測試：public void testGetStatus_inital() {// setupFlight flight = createAnonymousFlight()。// exercise SUT and verify outeassertEquals(, ())。// teardown// garbagecollected }public void testGetStatus_cancelled2() {// setupFlight flight = createAnonymousCancelledFlight()。// exercise SUT and verify outeassertEquals(, ())。// teardown// garbagecollected }注意，使用匿名創(chuàng)建方法(參見“創(chuàng)建方法”)來構(gòu)造每個測試中相應(yīng)狀態(tài)的Flight對象。 共享夾具(也稱為共享上下文、遺留夾具、重用的夾具、陳舊夾具) 如何避免緩慢測試？應(yīng)該使用哪種夾具策略？重用用于許多測試的測試夾具的相同實例。圖189 共享夾具示意圖要執(zhí)行自動化測試，需要易于理解且完全確定的測試夾具。建立新鮮夾具很耗費時間，特別是涉及存儲在測試數(shù)據(jù)庫中的復(fù)雜系統(tǒng)狀態(tài)時。重用幾個或許多測試的相同夾具可以讓測試運行更快。 運行原理基本思想相當簡單：創(chuàng)建標準夾具的夾具，它存在的時間比單個測試用例對象的生命周期還要長。這種方法允許多個測試重用相同的測試夾具，而不破壞該夾具或者在測試間再創(chuàng)建它。共享夾具可以是一個或多個測試在許多測試運行中重用的預(yù)制夾具，也可以是由一個測試創(chuàng)建、相同測試運行中另一個測試重用的夾具。在這兩種情況下，主要需要考慮的是許多測試沒有創(chuàng)建自己的夾具，而不是重用其他活動“遺留”的夾具。測試運行更快，因為它們需要實現(xiàn)的夾具建立更少，這使得測試自動化人員在定義每個測試的夾具時需要做的工作更少。 使用時機不管使用共享夾具的原因是什么，在使用它們之前都需要理解一些問題。共享夾具的主要問題是，它會導(dǎo)致測試間的交互，因此如果有些測試依賴其他測試的結(jié)果就可能導(dǎo)致不穩(wěn)定測試。另一個潛在問題是，用來服務(wù)許多測試的夾具一定比單個測試需要的最小夾具更復(fù)雜。更大的復(fù)雜性通常需要更多的努力來設(shè)計，以后需要修改夾具時，它還可能導(dǎo)致脆弱夾具(參見“脆弱測試”)。共享夾具通常導(dǎo)致模糊測試，因為在測試內(nèi)沒有構(gòu)造夾具。使用具有意圖明顯名稱[SBPP]的發(fā)現(xiàn)者方法(參見“測試實用程序方法”)來訪問夾具的相關(guān)部分，這樣可以緩解這種潛在不足。使用共享夾具有一些正當理由，也有一些被誤導(dǎo)的理由。設(shè)計了許多變體，主要目的是用來減輕使用共享夾具的負面效果。因此，使用共享夾具的正當理由是什么？1. 變體：緩慢測試不能為每個測試都構(gòu)建新的新鮮夾具時，可以使用共享夾具。當花費太多精力為每個測試構(gòu)建新夾具時，就會出現(xiàn)這種情況，這通常會導(dǎo)致緩慢測試。當由于創(chuàng)建記錄的成本高而使用實際測試數(shù)據(jù)庫測試時，最容易出現(xiàn)這種情況。使用SUT的API創(chuàng)建引用數(shù)據(jù)會加劇系統(tǒng)開銷的增長，因為SUT通常執(zhí)行大量輸入驗證，這可能包括閱讀一些剛寫的記錄。更好的解決方案是根本不與數(shù)據(jù)庫交互，從而讓測試運行更快。要獲得更詳細的信息，可參閱緩慢測試的解決方案以及“沒有共享夾具的更快測試”部分的內(nèi)容。沒有共享夾具的更快測試對緩慢測試的第一反應(yīng)通常是轉(zhuǎn)換為共享夾具方法。然而，還有其他幾種方法可用。這里介紹了一些項目的經(jīng)驗。偽造數(shù)據(jù)庫在早期的一個XP項目中，我們寫過大量訪問數(shù)據(jù)庫的測試。起初我們使用共享夾具，后來遇到了交互測試(參見“不穩(wěn)定測試”)以及測試運行沖突(參見“不穩(wěn)定測試”)，于是改為新鮮夾具方法。因為這些測試需要大量引用數(shù)據(jù)，它們需要很長時間運行。平均來說，對于SUT所做的每次與數(shù)據(jù)庫之間的來回讀或?qū)懀總€測試都做過很多次。運行包含數(shù)百個測試的整個測試套件需要15分鐘，這極大地影響了快速頻繁整合工作的能力。在那時，可以使用數(shù)據(jù)訪問層將SQL與代碼分離開。我們很快就發(fā)現(xiàn)，它允許用功能上等價的偽造數(shù)據(jù)庫(參見“偽造對象”)取代實際數(shù)據(jù)庫。我們開始使用簡單的HashTables來存儲鍵的對象。這種方法允許“在內(nèi)存里”而不是對數(shù)據(jù)庫運行許多更簡單的測試，這就極大地縮短了測試執(zhí)行時間。永久性架構(gòu)支持對象查詢接口?？梢詷?gòu)建對象查詢的解釋程序，這些對象查詢在HashTable數(shù)據(jù)庫實現(xiàn)中執(zhí)行，允許大多數(shù)測試都在內(nèi)存里運行。在內(nèi)存里運行測試比使用數(shù)據(jù)庫運行測試平均快50倍。例如，使用數(shù)據(jù)庫運行需要10分鐘的測試套件在內(nèi)存里運行只需要10s。這種方法非常成功，我們可以在后面許多項目上重復(fù)使用相同的測試基礎(chǔ)結(jié)構(gòu)。使用偽造永久性架構(gòu)也意味著，在對象模型穩(wěn)定之前，可能是項目中幾個月的時間，不必構(gòu)建“實際數(shù)據(jù)庫”。速度遞增Ted O’Grady和Joseph King領(lǐng)導(dǎo)大型eXtreme編程項目(50名以上開發(fā)人員、主題專家和測試人員)的敏捷開發(fā)小組。和構(gòu)建以數(shù)據(jù)庫為中心的應(yīng)用程序的許多項目小組一樣，他們也經(jīng)受了緩慢測試。但他們找到了解決這個問題的方法：到2005年年末，他們檢入的測試套件能夠在8分鐘內(nèi)運行，而使用數(shù)據(jù)庫運行整個測試需要8小時。這種速度的差別給人的印象非常深刻。下面是他們的故事：目前我們定期運行6700個測試。實際上我們嘗試了一些方法來加速測試，它們隨著時間的推移也不斷發(fā)展。2004年1月，通過Toplink對數(shù)據(jù)庫直接運行測試。2004年6月，修改了應(yīng)用程序，對內(nèi)存、進程中的Java數(shù)據(jù)庫(HSQL)運行測試。這讓運行時間減少了一半。2004年8月，創(chuàng)建了測試專用架構(gòu)，它允許Toplink不使用數(shù)據(jù)庫運行。這讓運行所有測試的時間減少了10倍。2005年7月，構(gòu)建了共享的“檢入”測試執(zhí)行服務(wù)器，它使我們能夠遠程運行測試。剛開始它沒有節(jié)省時間，但事實證明它非常有用。