用Spring實(shí)現(xiàn)非端到端驗(yàn)收測試

驗(yàn)收測試讓交付團(tuán)隊(duì)超越了基本的持續(xù)集成，即驗(yàn)證應(yīng)用程序是否為用戶提供了有價值的功能。不過對于剛開始嘗試部署流水線的團(tuán)隊(duì)來說，想要自動化驗(yàn)收測試，需要跨過三大門檻。

一是實(shí)現(xiàn)和維護(hù)驗(yàn)收測試的技術(shù)門檻。理想情況下，驗(yàn)收測試最好可以模擬用戶與應(yīng)用程序的真實(shí)交互，因此如果有圖形界面的話，驗(yàn)收測試?yán)響?yīng)通過這個界面和系統(tǒng)打交道。然而，直接通過GUI進(jìn)行測試會遇到幾個問題：界面變化速度很快、場景的準(zhǔn)備相對復(fù)雜、拿到測試結(jié)果較難等。比如一個典型的WEB應(yīng)用程序，如果通過GUI測試，那么一般需要解析HTML標(biāo)簽來填寫參數(shù)，提交表單，最后再次通過解析來獲取系統(tǒng)的返回值。如果測試代碼中充斥著操作HTML的細(xì)節(jié)，測試的可讀性就會大大下降，驗(yàn)收測試本身也更脆弱，在需求變更時反而會拖慢進(jìn)度。

二是交付團(tuán)隊(duì)工作方式的變化。在傳統(tǒng)團(tuán)隊(duì)中，需求分析、開發(fā)和測試是獨(dú)立而又順序的過程。就算能形成詳細(xì)的需求文檔，三方對同一段文字可能都有自己的理解。結(jié)果經(jīng)常出現(xiàn)偏差，需求分析人員抱怨開發(fā)人員沒有正確理解需求文檔，開發(fā)人員抱怨需求文檔不清晰、抱怨測試人員故意挑刺。敏捷實(shí)踐和驗(yàn)收測試的出現(xiàn)緩解了這一問題，通過預(yù)先定義驗(yàn)收規(guī)格，減少文字上的誤解，明確了開發(fā)工作的完成標(biāo)準(zhǔn)。不過這種思維方式的轉(zhuǎn)變很難一蹴而就，需要交付團(tuán)隊(duì)及其利益關(guān)系人共同持續(xù)努力才能成功。

三是對組織的環(huán)境、配置管理及部署流程的挑戰(zhàn)。當(dāng)引入自動化驗(yàn)收測試后，對整個部署流水線的自動化程度會有更高要求。比如部署流水線應(yīng)該能夠自動將應(yīng)用程序部署到待測試的環(huán)境中。如果應(yīng)用程序依賴數(shù)據(jù)庫，那么還應(yīng)該能夠部署數(shù)據(jù)庫schema。另外一些運(yùn)行時配置也需要通過腳本完成設(shè)置。這當(dāng)中除了腳本準(zhǔn)備之外，組織的環(huán)境管理也是要能跟上的。一般情況下，稍微大一些的組織都是有專門的運(yùn)維團(tuán)隊(duì)(而非交付團(tuán)隊(duì))來管理硬件設(shè)備和其配置的。因此，這個問題一般也涉及多個團(tuán)隊(duì)來協(xié)作解決。

面對這三座大山和進(jìn)度壓力，新手團(tuán)隊(duì)可能會感慨“信息量略大”而止步不前。這時不妨考慮各個擊破，三個問題中的工作方式轉(zhuǎn)變涉及的利益干系人最多，難度也最大;環(huán)境管理問題雖然涉及不同團(tuán)隊(duì)，但一般還是技術(shù)部門內(nèi)的問題，關(guān)起門來好商量;驗(yàn)收測試的實(shí)現(xiàn)/維護(hù)主要是技術(shù)問題，相對最簡單。如果時間和資源確實(shí)有限，不妨考慮犧牲一部分驗(yàn)收測試的有效性，采用簡單的非端到端驗(yàn)收測試，在自動化部署流程方面也可以做一些折中，集中力量轉(zhuǎn)變工作方式。當(dāng)整個工作已經(jīng)進(jìn)入節(jié)奏，再去改進(jìn)某個具體環(huán)節(jié)時就順利很多了。團(tuán)隊(duì)只要愿意邁出一小步，也能獲得很大的價值。

過渡方案：相對簡單的非端到端驗(yàn)收測試

如果團(tuán)隊(duì)的技術(shù)積累還不足，又沒有足夠的資源，不妨考慮簡單一些的驗(yàn)收測試策略作為過渡方案。非端到端的驗(yàn)收測試是指直接調(diào)用應(yīng)用程序內(nèi)部的邏輯結(jié)構(gòu)來驅(qū)動測試。由于測試代碼和產(chǎn)品代碼都使用同一種語言編寫，可以省去比較繁瑣的數(shù)據(jù)格式解析。而在準(zhǔn)備測試數(shù)據(jù)和場景時，直接調(diào)用內(nèi)部邏輯塊一般也更方便。以典型的使用SpringFramework的Java WEB應(yīng)用程序?yàn)槔瑘F(tuán)隊(duì)可以采用和集成測試類似的基礎(chǔ)架構(gòu)來編寫非端到端的驗(yàn)收測試。

這里所說的集成測試的目的是驗(yàn)證應(yīng)用程序與外部服務(wù)的連接能否正常工作。這與應(yīng)用程序?qū)崿F(xiàn)的具體功能關(guān)系不大，因此一般只加載必需的ApplicationContext。

圖表 1 集成測試

非端到端的驗(yàn)收測試可以采用和集成測試一樣的測試基礎(chǔ)架構(gòu)，這樣你就可以使用熟悉的測試庫了，不同的是需要加載整個ApplicationContext以盡可能模擬應(yīng)用程序被部署后的情況。

圖表 2 加載整個上下文

由于可以訪問整個ApplicationContext中的任一對象，我們可以通過訪問應(yīng)用程序的內(nèi)部組件來執(zhí)行測試，比如應(yīng)用層的某個Service。但需要注意的是，選取的組件離UI層越遠(yuǎn)，其模擬真實(shí)用戶交互的有效性就越差，而且受內(nèi)部實(shí)現(xiàn)變更的影響越大。如果應(yīng)用程序使用spring-webmvc的3.2以上版本，推薦使用它的mvc測試庫。spring-test-mvc提供了類似http請求的DSL，此時雖然測試還是基于ApplicationContext，但并不直接訪問內(nèi)部組件了。這個方案對于新手團(tuán)隊(duì)比較友善，但請注意，這僅僅是個過渡方案，因?yàn)椋?/p>

非端到端測試無法提供全面的回歸測試，尤其是UI操作。在好幾個項(xiàng)目中，我們發(fā)現(xiàn)僅采用非端到端測試覆蓋的功能，團(tuán)隊(duì)不得不保留手工回歸測試。如果UI上包含了大量復(fù)雜的控制邏輯甚至有業(yè)務(wù)邏輯泄漏到UI組件中，這會稀釋驗(yàn)收測試帶來的收益。

由于測試加載的ApplicationContext和Web容器加載的ApplicationContext存在差異，非端到端測試可能會漏掉一些問題。比如在非端到端測試中一次性加載了booking-servlet.xml和root.xml，使他們成為了一個整體的上下文，而實(shí)際上在Web容器中并不完全是這樣，root.xml中的bean并不能訪問和控制booking-servlet.xml中的bean。一個常見問題就是如果在booking-servlet.xml中需要使用占位符，而恰巧我們已經(jīng)在root.xml中有一個現(xiàn)成的，看起來水到渠成，而且在測試中也沒有問題，但實(shí)際部署到web容器時，就會加載失敗。

非端到端的驗(yàn)收測試不能作為任務(wù)完成的最終標(biāo)準(zhǔn)。因?yàn)檫€有UI部分還沒有完成。當(dāng)這類驗(yàn)收測試通過時，我把這個任務(wù)稱作“可以進(jìn)入UI調(diào)試的”。

因此，如果團(tuán)隊(duì)有足夠的技能和資源時還是應(yīng)該直接使用端到端的驗(yàn)收測試，尤其當(dāng)應(yīng)用程序提供API(比如WebService)或是采用更易于解析的數(shù)據(jù)格式與客戶端交互時。比如如果應(yīng)用程序提供了基于JSON的API，完全可以使用http-client來驅(qū)動測試。

實(shí)現(xiàn)非端到端的驗(yàn)收測試

來看看第一個驗(yàn)收測試，這個案例來自于著名的dddsample，為了讓驗(yàn)收測試能夠看上去高端大氣上檔次，我們將使用Cucumber來組織驗(yàn)收測試。驗(yàn)收場景描述的是業(yè)務(wù)員如何登記航運(yùn)貨件并解釋了登記完成后貨件的各項(xiàng)狀態(tài)。

圖表 3 第一個用戶故事及其驗(yàn)收場景

Cucumber提供了一系列的Annotation來幫助我們驗(yàn)收場景文本與測試代碼粘連在一起。

圖表 4實(shí)現(xiàn)驗(yàn)收測試-1

圖表 5 實(shí)現(xiàn)驗(yàn)收測試-2

接下來，當(dāng)運(yùn)行測試時，你就可以得到一份漂亮的html報(bào)告

圖表 6 測試運(yùn)行入口

維護(hù)非端到端的驗(yàn)收測試

當(dāng)團(tuán)隊(duì)開始編寫驗(yàn)收測試之后，一般沒過多久就會發(fā)現(xiàn)驗(yàn)收測試的開發(fā)進(jìn)度越來越慢，而且有時遇到測試失敗，但其實(shí)應(yīng)用程序并沒有缺陷的情況。驗(yàn)收測試對代碼質(zhì)量的要求也很高，相比單元測試，為了要達(dá)到測試所需的起始狀態(tài)，驗(yàn)收測試的準(zhǔn)備工作要更復(fù)雜。而且由于需要解析應(yīng)用程序返回的數(shù)據(jù)，驗(yàn)收測試的斷言也會更加瑣碎。因此，團(tuán)隊(duì)最好盡早開始重構(gòu)驗(yàn)收測試，下面的建議或許有用處：

建立最小測試數(shù)據(jù)集并且盡可能隔離測試的數(shù)據(jù)。有時團(tuán)隊(duì)會發(fā)現(xiàn)兩組測試由于依賴同一批數(shù)據(jù)而產(chǎn)生沖突，單獨(dú)執(zhí)行任一組測試都能通過，但一起執(zhí)行就會失敗。比如在示例代碼中，對于不同的貨件處理事件登記場景，驗(yàn)收測試都會注冊一個新的貨件。

隱藏?cái)嘌约?xì)節(jié)。這樣可以減少重復(fù)代碼，并提升測試的可讀性。把瑣碎的解析邏輯隱藏在領(lǐng)域語言編寫的方法中。

例如：如果多個測試用例都會對貨件的運(yùn)輸狀態(tài)進(jìn)行斷言，可以把解析細(xì)節(jié)提取出來，這樣可以去除重復(fù)代碼，并且減少語法噪聲。

圖表 7 抽取斷言

盡可能使用已實(shí)現(xiàn)的功能來實(shí)現(xiàn)測試場景的準(zhǔn)備。有一些步驟可能是多個測試用例都需要來準(zhǔn)備數(shù)據(jù)的，可以把此類步驟抽取出來。這樣也可以減少重復(fù)的代碼，當(dāng)應(yīng)用程序隨著需求變化時，驗(yàn)收測試會有更強(qiáng)的適應(yīng)性，而且抽取出來的方法由于隱藏了技術(shù)細(xì)節(jié)，使用起來更簡練。直接使用數(shù)據(jù)腳本的方案看起來很誘人，但一旦內(nèi)部結(jié)構(gòu)改變，數(shù)據(jù)腳本也得跟著改。

圖表 8 抽取公共步驟

驗(yàn)收測試對實(shí)踐部署流水線的團(tuán)隊(duì)有著重要意義，也是很大的挑戰(zhàn)。希望大家都能找到合適自己的方法。最后介紹幾個有用的測試庫。

Moco，當(dāng)有外部系統(tǒng)集成需求時，集成測試和驗(yàn)收測試的一大利器。在示例代碼中你可以找到一處例子。

GreenMail，如果應(yīng)用程序需要發(fā)送郵件的話，它可以提供一臂之力。不過在部署流水線上的端到端驗(yàn)收測試中，由于一般應(yīng)用程序和測試并不運(yùn)行在同一臺機(jī)器上，很難對郵件進(jìn)行直接的斷言。這時一種方案是修改應(yīng)用程序的架構(gòu)，把發(fā)送郵件的實(shí)現(xiàn)分離到一個專用的應(yīng)用中去并使用消息隊(duì)列集成。那么在驗(yàn)收測試中，我們就可以通過監(jiān)聽對應(yīng)的消息隊(duì)列來斷言了。

Awaitility，在需要對異步處理進(jìn)行斷言時有所幫助。