【文章內容簡介】 Unit變體允許指定失敗的斷言不中止測試方法的執(zhí)行。q 需要確保出現(xiàn)失敗時，斷言失敗能說出正在執(zhí)行哪個子測試。在循環(huán)中包含try/catch語句，同時包含測試邏輯然后繼續(xù)代碼執(zhí)行，這樣可以解決最后兩個問題。然而，仍然需要能夠以一種有意義的方法報告測試結果(例如，“失敗子測試3和6以及……”)。要更方便地擴充數(shù)據(jù)驅動測試解釋程序來處理相同數(shù)據(jù)文件中幾種不同類型的測試，可以包含“動詞”或“動作單詞”作為數(shù)據(jù)文件中各條目的一部分。解釋程序可以依據(jù)動作單詞分派給不同的參數(shù)化測試。3. 變體：測試套件對象生成器讓測試套件工廠(參見“測試枚舉”)上的suite方法偽造與測試發(fā)現(xiàn)內置機制相同的測試套件對象結構，就可以避免與天真xUnit測試解釋程序相關的“第一次失敗時就停止”這個問題。要這樣做，可以為數(shù)據(jù)驅動測試文件中的每個條目構建測試用例對象，然后用特定測試的測試數(shù)據(jù)初始化每個對象6 這與xUnit的內置測試方法發(fā)現(xiàn)(參見“測試發(fā)現(xiàn)”)機制的運行原理類似，但后者接受的是測試數(shù)據(jù)和測試方法名稱。構建測試套件時，該對象知道如何執(zhí)行具有加載數(shù)據(jù)的參數(shù)化測試。這樣即使第一個測試用例對象遇到斷言失敗，也可以確保數(shù)據(jù)驅動測試能夠繼續(xù)執(zhí)行。因此，可以讓測試運行器以正常方式計算測試、錯誤及失敗。4. 變體：測試套件對象模擬器構建測試套件對象的方法之一是創(chuàng)建像一個對象那樣運行的測試用例對象。要求運行時該對象會閱讀數(shù)據(jù)驅動測試文件并重新執(zhí)行所有測試。它必須捕獲參數(shù)化測試拋出的所有異常，然后繼續(xù)執(zhí)行后面的測試。完成后，測試用例對象必須給測試運行器報告測試、失敗和錯誤的準確數(shù)量。它也要實現(xiàn)測試運行器依賴的標準測試接口上的其他方法，例如返回“套件”中測試的數(shù)量、返回套件中每個測試的名稱和狀態(tài)(關于圖形測試樹探測器，參見“測試運行器”)。 啟發(fā)示例假設有一組測試如下所示：def test_extrefsourceXml = extref id=39。abc39。 /expectedHtml = a href=39。39。abc/agenerateAndVerifyHtml(sourceXml,expectedHtml,extref)enddef test_testterm_normalsourceXml = testterm id=39。abc39。/expectedHtml = a href=39。39。abc/agenerateAndVerifyHtml(sourceXml,expectedHtml,testterm)enddef test_testterm_pluralsourceXml = testterms id=39。abc39。/expectedHtml = a href=39。39。abcs/agenerateAndVerifyHtml(sourceXml,expectedHtml,plural)end如下定義參數(shù)化測試可以簡化這些測試：def generateAndVerifyHtml( sourceXml, expectedHtml,message, amp。block) mockFile = !(\t)@handler = setupHandler(sourceXml, mockFile ) unless block = = nil @ actual_html = assert_equal_html( expectedHtml, actual_html, message + html output) actual_html end這些測試存在的主要問題是，這些測試還是用代碼寫的，而實際上它們之間的唯一不同是用作輸入的數(shù)據(jù)。 重構說明當然，解決方案是將參數(shù)化測試的公共邏輯提取到數(shù)據(jù)驅動測試解釋程序中，并將所有參數(shù)集合到任何人都可以編輯的單個數(shù)據(jù)文件中。需要寫“主”測試，它知道從哪個文件閱讀測試數(shù)據(jù)，知道閱讀和分析測試文件的一些邏輯。該邏輯可以調用現(xiàn)有的參數(shù)化測試邏輯，并讓xUnit記錄測試執(zhí)行統(tǒng)計。 示例：使用XML數(shù)據(jù)文件的xUnit數(shù)據(jù)驅動測試本示例中，使用XML形式文件。每個測試都由test元素組成，它有三個主要部分：q 告訴數(shù)據(jù)驅動測試解釋程序要運行哪種測試邏輯的動作(例如，crossref)。q 傳遞給SUT的輸入，這里是sourceXml元素q 希望SUT(在expectedHtml元素中)生成的HTML這三個部分包裝在testsuite元素里：testsuite id=CrossRefHandlerTest test id=extrefactioncrossref/action sourceXmlextref id=39。abc39。/ /sourceXml expectedHtmla href=39。39。abc/a /expectedHtml /test test id=TestTermactioncrossref/action sourceXmltestterm id=39。abc39。/ /sourceXml expectedHtmla href=39。39。abc/a /expectedHtml /testtest id=TestTerm Plural actioncrossref/action sourceXmltestterms id=39。abc39。/ /sourceXml expectedHtmla href=39。39。abcs/a/expectedHtml /test /testsuite所有擁有XML編輯器的人都可以編輯這個XML文件，而不必擔心引入測試邏輯錯誤。數(shù)據(jù)驅動測試解釋程序封裝用來驗證預期結果的所有邏輯，使用的方法與參數(shù)化測試使用的方法相同。出于查看的目的，通過定義樣式表對用戶隱藏了XML的結構。另外，許多XML編輯器會將XML轉換為基于表格的輸入以簡化編輯。為了避免處理操作XML的復雜性，解釋程序也可以使用CSV文件作為輸入。 示例：使用CSV輸入文件的xUnit數(shù)據(jù)驅動測試使用CSV文件，前面示例中的測試則如下所示：ID, Action, SourceXml, ExpectedHtml Extref,crossref,extref id=39。abc39。/,a href=39。39。abc/a TTerm,crossref,testterm id=39。abc39。/,a href=39。39。abc/a TTerms,crossref,testterms id=39。abc39。/,a href=39。39。abcs/a這個解釋程序相對簡單，并且建立在為參數(shù)化測試而開發(fā)的邏輯之上。它閱讀CSV文件，并使用Ruby的split函數(shù)分析各行。def test_crossrefexecuteDataDrivenTest enddef executeDataDrivenTest filename dataFile = (filename) do | line |desc, action, part2 = (,) sourceXml, expectedHtml, leftOver = (,) if crossref= =generateAndVerifyHtml sourceXml, expectedHtml, desc else new verbs go before here as elsif39。sreport_error( unknown action + ) end end end除非將generateAndVerifyHtml的實現(xiàn)方式改變?yōu)椴东@斷言失敗和增加失敗計數(shù)器，這種數(shù)據(jù)驅動測試才會在遇到第一個失敗斷言時停止執(zhí)行。而回歸測試可以接受這種行為，雖然它沒有提供很好的缺陷定位。 示例：使用Fit架構的數(shù)據(jù)驅動測試如果要進一步控制用戶的行為，可以創(chuàng)建Fit“列夾具”，其中有id、action、source XML和expected Html()各列，讓用戶編輯HTML Web頁面(如表181所示)。表181 使用Fit架構構建的數(shù)據(jù)驅動測試idactionsource XMLexpected HtrnlOExtrefcrossrefextref id=39。abc39。 /a href=39。39。?abc?/aTestTermcrossreftestterm id=39。abcd39。 /a href=39。39。?abc?/aTestTerm Pluralcrossreftestterm id=39。abc39。 suffix=s/a href=39。39。?abcs?/a使用Fit時，測試解釋程序是測試專用的Fit夾具類擴充的Fit架構：public class CrossrefHandlerFixture extends ColumnFixture { // Input columns public String id。public String action。 public String sourceXML。// Output columnspublic String expectedHtml() {return generateHtml(sourceXML)。 }}Fit架構依據(jù)列標題，為Fit表中每一行的每一個單元調用這種夾具類的方法。簡單的名稱解釋為夾具的實例變量(例如id、source XML)。以()結尾的列名稱表示Fit調用的函數(shù)，然后將其結果與單元格內容作比較。結果輸出如表182所示。這種帶陰影的表格非常便于總結運行測試文件后的結果。表182 執(zhí)行Fit測試的結果. idActionsource XMLexpected HtrnlQextrefcrossrefextref id=39。abc39。 /a href=39。abc .html39。 ?abc?/aTestTermcrossreftestterm id=39。abcd39。 /a href=39。 abc .html39。 ?abc?/aTestTerm Pluralcrossreftestterm id=39。abc39。 suffix=s/a href=39。39。?abcs?/a 預期a href=39。abc. html39。?abc?/a 實際 測試自動化架構 如何讓編寫和運行不同人寫的測試更方便？可以使用架構，該架構提供運行測試邏輯所需的所有機制，因此測試作者只需要提供測試專用邏輯就行了。寫和運行自動化測試包含幾個步驟，但對于每個測試而言其中許多步驟都相同。如果每個測試都必須包含這些步驟的實現(xiàn)方式，寫自動化測試就變得很單調、很耗時間、容易出錯并且成本很高。使用測試自動化架構是一種最小化寫全自動化測試努力的方法。圖184 測試自動化架構示意圖 運行原理可以構建一種架構，它實現(xiàn)運行測試套件和記錄結果所需的所有機制。這些機制能夠找出單個測試、將它們組合為測試套件、依次執(zhí)行每個測試、驗證預期結果、收集和報告測試失敗或錯誤以及發(fā)生失敗或錯誤時能夠清除它們。這種架構提供了一種方法來插入并運行測試自動化人員寫的測試專用行為。 這樣做的原因構建可重復且健壯的全自動化測試，該過程比寫調用SUT的測試腳本更復雜。需要應付成功情況和錯誤情況，以及預期結果與意外結果。需要建立和拆卸測試夾具，需要指定運行哪個(哪些)測試，運行一組測試后還要報告結果。構建全自動化測試需要的努力可能是測試自動化的嚴重阻礙。只提供實現(xiàn)最常見功能性的架構，可以大大降低啟動成本，學習使用架構時，才需要付出唯一的入門成本。同樣，如果實現(xiàn)公共協(xié)議還可以降低成本，例如xUnit，在熟悉第一個架構之后，更容易學習第二或者第三個架構。使用架構也有助于將運行測試所需邏輯的實現(xiàn)方式與測試邏輯隔離開。這種方法有助于減少測試碼復制和最小化模糊測試發(fā)生的概率。它還可以確保不同測試自動化人員寫的測試可以方便地在單個測試運行中運行，并可以提供測試結果的單獨報告。 實現(xiàn)方式說明有許多種測試自動化架構可用，既有商業(yè)廠商的，也有開源資源。它們可分為兩大類：“機器人用戶”測試工具和腳本測試。后面一類可進一步細分為測試自動化架構下的xUnit和數(shù)據(jù)驅動測試家族。1. 變體：機器人用戶測試架構許多第三方測試自動化工具可以通過用戶界面測試應用程序。其中大多數(shù)使用“記錄與回放”測試隱喻。這種隱喻提供了一些非常誘人的營銷材料，因為記錄測試會話時，它讓測試自動化就像手動運行一些測試那樣簡單。這種機器人用戶測試工具由兩個主要部分組成：“測試記錄器”，它監(jiān)控和記錄用戶與SUT之間的交互；“測試運行器”，它執(zhí)行記錄的測試。大多數(shù)測試自動化工具也是架構，這些架構支持許多“構件識別器”插件。大多數(shù)商業(yè)工具都有一批內置的構件識別器。2. 變體：測試自動化架構的xUnit家族大多數(shù)單元測試工具屬于自動化手寫腳本測試(參見“腳本測試”)的測試架構的xUnit家族。xUnit已經移植到(或者重新開發(fā))當前大多數(shù)編程語言。單元測試架構的xUnit家族由幾個主要組件組成。最顯而易見的是測試運行器，可以從命令行或者作為圖形測試運行器(參見“測試運行器”)調用它。它構建測試用例對象，將它們集合到測試套