企業系統集成點測試策略

　　集成是企業應用系統中繞不開的話題。與外部系統的集成點不僅實現起來麻煩，更是難以測試。本文介紹了一種普遍適用的集成點測試策略，兼顧測試的覆蓋程度、速度、可靠性和可重復性，為集成點的實現與測試建立一個通用的參考。

　　背景

　　本文作為例子介紹的系統是一個典型的JavaEE Web應用，基于Java 6和Spring開發，采用Maven構建。該系統需要以XML over HTTP的方式集成兩個外部系統。

　　該系統由一支典型的分布式團隊交付：業務代表平常在墨爾本工作，交付團隊則分布在悉尼和成都。筆者作為技術領導者帶領一支成都的團隊承擔主要交付任務。

　　痛點

　　由于需要集成兩個外部系統，我們的Maven構建[1]過程中有一部分測試(使用JUnit)是與集成相關的。這部分測試給構建過程造成了一些麻煩。

　　首先是依賴系統的可靠性問題。在被依賴的兩個服務之中，有一個服務部署在開發環境中的實例經常會關機維護，而它一旦關機就會導致與其集成的測試無法通過，進而導致整個構建失敗。我們的交付團隊嚴格遵守持續集成實踐：構建失敗時不允許提交代碼。這么一來，當我們依賴的服務關機維護時，交付團隊正常的工作節奏就會被打亂。

　　即使沒有關機維護，由于開發環境中部署的服務實例仍在不斷測試和調優，被依賴的服務實例也不時出現運行性能低、響應時間長等問題，使我們的構建過程也變得很慢，有時甚至會出現隨機的構建失敗。

　　被依賴的服務在開發環境下不可靠、性能低，會使應用程序的構建過程也隨之變得脆弱而緩慢，從而打擊程序員頻繁進行構建的積極性，甚至損害持續集成的有效性。作為團隊的技術領導者，我希望解決這個問題，使構建可靠而快速地運行，以確保所有人都愿意頻繁執行構建。

　　如何測試集成點

　　在一個基于Spring的應用中，與外部服務的集成通常會被封裝為一個Java接口以及其中的若干方法。例如“創建某品牌的用戶”的服務很可能如下呈現：

　　public interface IdentityService {Customer create(Brand brand, Customer customer);

　　一個實現了IdentityService接口的對象會被Spring實例化并放入應用上下文，需要使用該服務的客戶代碼可以通過依賴注入獲得該對象的引用，從而調用它的create方法。在測試這些客戶代碼時，始終可以mock一個IdentityService對象，將其注入被測對象，從而解耦對外部服務的依賴。這是使用依賴注入帶來的收益。

　　因此，我們的問題主要聚焦于集成點本身的測試。

　　用面向對象的語言來集成一個基于HTTP的服務，集成點的設計經常會出現這樣一個模式，其中涉及五個主要的組成部分：門面(Façade);請求構造器(Request Builder);請求路由器(Request Router);網絡端點(Network End Point);應答解析器(Response Parser)。它們之間的交互關系如下圖：

　　顯而易見，在這個模式中，真正需要發出網絡請求的只有網絡端點這個組件。該組件的作用即是“按照預先規定好的通信方式，向給定的網絡地址發出給定的請求，返回應答內容”。對于基于HTTP的服務集成而言，網絡端點的接口大致如下呈現：

　　public interface EndPoint {Response get(String url);Response post(String url, String requestBody);Response put(String url, String requestBody);

　　其中Response類包含兩項主要信息：HTTP返回碼，以及應答正文。

　　public class Response {private final int statusCode;private final String responseBody;

　　不難注意到，EndPoint類所關心的是把正確的請求發送到正確的地址、取回正確的應答。它并不關心這個地址究竟是什么(這是請求路由器組件的責任)，也不關心請求與應答包含什么信息(這是請求構造器和應答解析器的責任)。這一特點使得EndPoint類的測試完全不需要依賴真實服務的存在。

　　網絡端點的測試

　　如前所述，EndPoint類并不關心發送請求的地址，也不關心請求與應答的內容，只關心以正確的方式來發送請求并拿回應答——“正確的方式”可能包括身份認證與授權、必要的HTTP頭信息等。為了測試這樣一個類，我們不需要朝真正的網絡服務地址發送請求，也不需要遵循真實的請求/應答協議，完全可以自己創造一個HTTP服務，用最簡單的請求/應答文本來進行測試。

　　Moco[2]就是專門用于這種場合的測試工具。按照作者的介紹，Moco是“一個非常容易設置的stub框架，主要用于測試與集成”。在 JUnit測試中，只需要兩行代碼就可以聲明一個HTTP服務器，該服務器監聽12306端口，對一切請求都會以字符串“foo”作為應答：

　　MocoHttpServer server = httpserver(12306);server.reponse("foo");

　　接下來就可以像訪問正常的服務器一樣，用Apache Commons HTTP Client來訪問這個服務器。唯一需要注意的是，訪問服務器的代碼需要放在running塊中，以確保服務器能被正常關閉：

　　running(server, new Runnable() {

　　@Override

　　public void run() throws IOException {

　　Content content = Request.Get("http://localhost:12306").execute().returnContent();

　　assertThat(content.asString(), is("foo"));

　　}

　　}

　　當然，作為一個測試輔助工具，Moco支持很多靈活的配置，感興趣的讀者可以自行查閱文檔。接下來我們就來看如何用Moco來測試我們系統中的網絡端點組件。作為例子，我們這里需要集成的是用于管理用戶身份信息的OpenPTK[3]。OpenPTK使用自定義的XML通信協議，并且每次請求之前要求客戶端程序先向/openptk-server/login地址發送應用名稱和密碼以確認應用程序的合法身份。為此，我們先準備一個Moco server供測試之用：

　　server = httpserver(12306);

　　server.post(and(

原文轉自：http://www.infoq.com/cn/articles/enterprise-systems-integration-points