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