用Spring實現非端到端驗收測試

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

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

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

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

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

過渡方案：相對簡單的非端到端驗收測試

如果團隊的技術積累還不足，又沒有足夠的資源，不妨考慮簡單一些的驗收測試策略作為過渡方案。非端到端的驗收測試是指直接調用應用程序內部的邏輯結構來驅動測試。由于測試代碼和產品代碼都使用同一種語言編寫，可以省去比較繁瑣的數據格式解析。而在準備測試數據和場景時，直接調用內部邏輯塊一般也更方便。以典型的使用SpringFramework的Java WEB應用程序為例，團隊可以采用和集成測試類似的基礎架構來編寫非端到端的驗收測試。

這里所說的集成測試的目的是驗證應用程序與外部服務的連接能否正常工作。這與應用程序實現的具體功能關系不大，因此一般只加載必需的ApplicationContext。

圖表 1 集成測試

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

圖表 2 加載整個上下文

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

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

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

非端到端的驗收測試不能作為任務完成的最終標準。因為還有UI部分還沒有完成。當這類驗收測試通過時，我把這個任務稱作“可以進入UI調試的”。

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

實現非端到端的驗收測試

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

圖表 3 第一個用戶故事及其驗收場景

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

圖表 4實現驗收測試-1

圖表 5 實現驗收測試-2

接下來，當運行測試時，你就可以得到一份漂亮的html報告

圖表 6 測試運行入口

維護非端到端的驗收測試

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

建立最小測試數據集并且盡可能隔離測試的數據。有時團隊會發現兩組測試由于依賴同一批數據而產生沖突，單獨執行任一組測試都能通過，但一起執行就會失敗。比如在示例代碼中，對于不同的貨件處理事件登記場景，驗收測試都會注冊一個新的貨件。

隱藏斷言細節。這樣可以減少重復代碼，并提升測試的可讀性。把瑣碎的解析邏輯隱藏在領域語言編寫的方法中。

例如：如果多個測試用例都會對貨件的運輸狀態進行斷言，可以把解析細節提取出來，這樣可以去除重復代碼，并且減少語法噪聲。

圖表 7 抽取斷言

盡可能使用已實現的功能來實現測試場景的準備。有一些步驟可能是多個測試用例都需要來準備數據的，可以把此類步驟抽取出來。這樣也可以減少重復的代碼，當應用程序隨著需求變化時，驗收測試會有更強的適應性，而且抽取出來的方法由于隱藏了技術細節，使用起來更簡練。直接使用數據腳本的方案看起來很誘人，但一旦內部結構改變，數據腳本也得跟著改。

圖表 8 抽取公共步驟

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

Moco，當有外部系統集成需求時，集成測試和驗收測試的一大利器。在示例代碼中你可以找到一處例子。

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

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