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