14.6?Spring MVC 測試框架（每天翻譯一點點）

Spring MVC測試框架對?Spring MVC 代碼提供一流的測試支持?，它擁有一個?fluent API?,可以和JUnit, TestNG 或其它任何測試框架協同使用。?此測試框架基于?spring-test?模塊的Servlet API mock objects?的，因此不需要依賴運行Servlet 容器來完成測試。它使用DispatcherServlet? 來提供完整的Spring MVC運行時行為（full Spring MVC runtime behavior），并且支持加載項目實際使用的spring 配置，通過TestContext框架實現。除此之外，使用單例模式（standalone mode）創建的?controller 可以手動實例化，一次只測試一個實例。?

Spring MVC測試框架還提供了客戶端（Client-side）測試支持，使用RestTemplate。客戶端測試可以模擬服務器的響應，并且通常不需要啟動服務器。

	Spring Boot 框架可以編寫完善的、端到端的集成測試，包括對運行服務器的測試。假如你需要測試時同時測試服務器等運行環境， ?可以瀏覽一下?Spring Boot reference page. 更多關于容器外測試和端到端集成測試的區別，請看?the section called “Differences between Out-of-Container and End-to-End Integration Tests”.

14.6.1?服務器端測試

很容易寫一個普通的測試來測試Spring MVC 的controller，使用JUnit或TestNG：簡單的實例化一個?controller，并注入模擬依賴，然后直接通過?MockHttpServletRequest,?MockHttpServletResponse等調用?controller?的方法就可以了。然而，這樣一個測試方法，還有很多東西沒有測到：比如請求映射，數據綁定，類型轉換，驗證等等。?更有甚者, controller 的其它方法，例如?@InitBinder,?@ModelAttribute,和@ExceptionHandler?也可能作為請求進程生命周期的一部分被調用。

Spring MVC 測試的目標是通過實際的?DispatcherServlet發送請求和生成響應，為測試?controller?提供一個高效的途徑。

Spring MVC Test?builds on the familiar?"mock" implementations of the Servlet API?available in the?spring-test?module. 如此便可以在不用運行服務器的情況下發送請求和生成響應。絕大多數情況，這都和運行在?runtime 毫無區別，少數明顯的區別參考?“基于容器測試和端到端集成測試的區別”. 下面是一個基于JUnit 的?Spring MVC 測試的例子。

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*; import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;@RunWith(SpringJUnit4ClassRunner.class) @WebAppConfiguration @ContextConfiguration("test-servlet-context.xml") public class ExampleTests {@Autowiredprivate WebApplicationContext wac;private MockMvc mockMvc;@Beforepublic void setup() {this.mockMvc = MockMvcBuilders.webAppContextSetup(this.wac).build();}@Testpublic void getAccount() throws Exception {this.mockMvc.perform(get("/accounts/1").accept(MediaType.parseMediaType("application/json;charset=UTF-8"))).andExpect(status().isOk()).andExpect(content().contentType("application/json")).andExpect(jsonPath("$.name").value("Lee"));}}

上面的測試依賴于TestContext框架的??WebApplicationContext?類的支持，這個類用于從與被測代碼同一個包下的 XML 配置文件中加載 Spring 的配置，另外，也支持?Java-based 或?Groovy-based 的配置方式，參考?sample tests.

上面代碼中的?MockMvc?類的實例是用來發送一個 ?GET?請求給?"/accounts/1"?，然后驗證響應的狀態碼是否 200，響應類型是否是"application/json", 以及響應主體是否有一個 "name" 屬性，它的值是 "Lee". 代碼中?jsonPath?的語法參考 Jayway 提供的?JsonPath project. 除上文提及的之外，還許多請求響應結果的驗證方式將會在下文討論。

靜態導入

上述例子中的 fluent API 需要導入一些靜態依賴，例如MockMvcRequestBuilders.*,?MockMvcResultMatchers.*, 和MockMvcBuilders.*. 一個簡單的找到這些類的方法是，搜索匹配表達式"MockMvc*"?的類型。假如使用的是Eclipse，一定要將這些項添加到“favorite static members”里，在Eclipse的preference下的Java → Editor → Content Assist → Favorites里.這將使得你只需要輸入這些靜態方法的第一個字母，content assist 就會幫你彈出方法全名。其它IDE (如 IntelliJ) 或許不需要任何額外配置，只需要檢查是否開啟了對靜態成員的自動代碼完成功能?.

可選創建MockMvc實例的方式

現在主要有兩種創建MockMvc類實例的方式。第一種是通過TestContext?框架加載Spring-MVC的配置文件，然后將?WebApplicationContext?的對象注入到測試代碼，并用它作為初始化參數來構建一個??MockMvc?實例：

@RunWith(SpringJUnit4ClassRunner.class) @WebAppConfiguration @ContextConfiguration("my-servlet-context.xml") public class MyWebTests {@Autowiredprivate WebApplicationContext wac;private MockMvc mockMvc;@Beforepublic void setup() {this.mockMvc = MockMvcBuilders.webAppContextSetup(this.wac).build();}// ...}

第二種只是手動創建測試控制器（如：new AccountController()）而不用加載Spring配置文件。與默認配置方式不一樣，這種方式與Spring MVC基于Java類或MVC命名空間的配置方式很類似，都是能自動創建上下文并且能通過配置進行定制。

public class MyWebTests {private MockMvc mockMvc;@Beforepublic void setup() {this.mockMvc = MockMvcBuilders.standaloneSetup(new AccountController()).build();}// ...}

你更青睞于使用哪種初始化方式呢?

"webAppContextSetup"?方式加載的是你真正的Spring MVC配置文件，因此是更純粹更徹底的集成測試方法。而因為 TestContext? 框架會緩存了已加載的Spring配置，所以這種方式能讓測試跑得更快，即便它的測試套件（test suite）中包含了更多測試案例（test case）。更有用的是，你可以通過Spring配置文件將mock出的service注入到Controller 中，以此集中精力進行 web 層面的測試，而不用分散精力來對付Service層。如下，使用?Mockito 框架聲明一個 mock 服務類：

<bean id="accountService" class="org.mockito.Mockito" factory-method="mock"><constructor-arg value="org.example.AccountService"/> </bean>

然后，你可以將mock 服務類的對象注入到測試中，用來構建Controller 以及驗證異常：

@RunWith(SpringJUnit4ClassRunner.class) @WebAppConfiguration @ContextConfiguration("test-servlet-context.xml") public class AccountTests {@Autowiredprivate WebApplicationContext wac;private MockMvc mockMvc;@Autowiredprivate AccountService accountService;// ...}

"standaloneSetup"?方式有點像單元測試，它在某一個時間點只能測試一個Controller，這個 Controller 也可以手動注入mock依賴，并且它不會加載Spring配置文件。這種方式更關注于測試風格，使得我們更容易辨別要測試的是哪個類，而不用去管使用的是哪個配置文件。"standaloneSetup" 方式可以非常方便的寫出?ad-hoc 測試，用來驗證代碼特定特點或者調試某個問題。

和任何“集成測試和單元測試”之爭一樣，沒有誰對誰錯。然而，使用"standaloneSetup" 方式沒有實現測試"webAppContextSetup"的需求，也就沒有辦法驗證你的Spring MVC配置是否正確。要想避免，你就得所有測試都使用?"webAppContextSetup" ?方式創建，以便能測試到你真正的Spring MVC配置。

發送請求

使用perform()來發送任何HTTP請求都很簡單：

mockMvc.perform(post("/hotels/{id}", 42).accept(MediaType.APPLICATION_JSON));

你也可以在perform()內部使用 ?MockMultipartHttpServletRequest?? 對象發送文件上傳請求，這樣雖沒有真正解析一個的 multipart 請求，但看起來和真正解析了請求并沒什么區別：

mockMvc.perform(fileUpload("/doc").file("a1", "ABC".getBytes("UTF-8")));

你也可以使用URI模板（URI template）的方式設置琴酒參數：

mockMvc.perform(get("/hotels?foo={foo}", "bar"));

或者以表單參數（query of form parameters）方式增加一個請求參數：

mockMvc.perform(get("/hotels").param("foo", "bar"));

如果程序依賴于請求的參數，但沒嚴格的（explicitly?）檢查查詢字符串（這樣的事經常發生），那么不管你使用上面哪種方式來攜帶參數都不會出現問題。但需要注意的是，如果使用URI模板方式，這些參數將會被解碼（decoded），而使用?param(…?)?方式的話，則這些參數會被看做早已解碼了，也就不在解碼了。?

多數情況下，我們都不需要考慮 context path 和 Servlet path。但是如果你確實需要測試完整的URI，請確保設置好了相應的?contextPath和?servletPath??，這樣請求映射（request mapping） 才能起作用。

mockMvc.perform(get("/app/main/hotels/{id}").contextPath("/app").servletPath("/main"))

從上面的例子可見，如果每發送一個模擬請求都設置一下?contextPath 和 servletPath，那是相當的麻煩。所以，你可以通過設置“請求的默認屬性”來代替：

public class MyWebTests {private MockMvc mockMvc;@Beforepublic void setup() {mockMvc = standaloneSetup(new AccountController()).defaultRequest(get("/").contextPath("/app").servletPath("/main").accept(MediaType.APPLICATION_JSON).build();}

上面例子中通過 mockMvc?設置的的屬性對每個請求都起作用。假如一個屬性設置了默認值，但在某個請求里又被賦了新值，那么新值就會覆蓋掉默認值。這也是為什么在默認請求里設置的HTTP方法和URI沒什么用，因為每個請求都會重新指定它們。?

定義運行結果期望（Expectations）

運行結果期望可以在perform()方法后附加一個或多個?.andExpect(..)?來定義：

mockMvc.perform(get("/accounts/1")).andExpect(status().isOk());

MockMvcResultMatchers.*? 類下面提供了一系列期望，一些還嵌套了更具體的期望。

這些期望可以分為兩大類。第一類斷言驗證響應的屬性，例如，響應的狀態，響應頭，響應內容。對于斷言來說，這些響應結果是最重要的驗證對象。?

第二類斷言放在響應的后面。這種類型的斷言可以對Spring MVC的某些特殊對象進行檢查。例如，檢查控制器的哪個方法處理了請求，是否拋出了某個異常以及該異常是否已被處理，檢查模型對象的內容，檢查控制器返回了哪個視圖，或者是否添加了某個flash屬性等等。除此之外，這些斷言也可以用來檢查原生的Servlet的屬性，例如request和session的屬性。

下面的測試使用第二類斷言，假設數據綁定或校驗失敗：

mockMvc.perform(post("/persons")).andExpect(status().isOk()).andExpect(model().attributeHasErrors("person"));

通常在寫測試的時候，轉儲請求執行的結果是非常有用的，通常是轉儲到控制臺輸出。轉儲操作的例子如下，其中?print()?方法是從MockMvcResultHandlers靜態引入的：

mockMvc.perform(post("/persons")).andDo(print()).andExpect(status().isOk()).andExpect(model().attributeHasErrors("person"));

只要請求執行過程中沒有拋出未處理的異常，?print()?方法就會輸出所有結果數據到System.out.打印出來。 SSpring 4.2包含一個?log()?方法和兩個重載的?print()?方法,一個接受?OutputStream?作參數，另外一個接受?Writer.作參數。例如：使用?print(System.err)?會輸出結果到?System.err;里打印；使用?print(myWriter)?會輸出結果到自定義的writer類里打印.如果你希望把請求執行的結果保存到日志里，只需要調用?log()?方法就可以，它會記錄一條?DEBUG?級別的日志到org.springframework.test.web.servlet.result?目錄下。

某些情況下，我們的斷言需要并且只能在請求執行結果中驗證，這可以通過在末尾添加一個?.andReturn()方法來實現：

MvcResult mvcResult = mockMvc.perform(post("/persons")).andExpect(status().isOk()).andReturn(); // ...

假如一個斷言需要多次出現在不同的測試中，則可以設置成公共斷言，綁定到?MockMvc?實例上:

standaloneSetup(new SimpleController()).alwaysExpect(status().isOk()).alwaysExpect(content().contentType("application/json;charset=UTF-8")).build()

需要注意的是，公共斷言每次測試都會執行并且不會被在測試方法內部創建的獨立的?MockMvc?對象覆蓋掉。

如果控制器返回的是是JSON類型的響應，響應體里面攜帶了由?Spring HATEOAS?創建的超鏈接。t則這個鏈接可以使用JsonPath表達式來驗證：

mockMvc.perform(get("/people").accept(MediaType.APPLICATION_JSON)).andExpect(jsonPath("$.links[?(@.rel == ''self'')].href").value("http://localhost:8080/people"));

如果控制器返回的是是XML類型的響應，響應體里面攜帶了由?Spring HATEOAS，創建的超鏈接，則這個鏈接可以使用XPath表達式來驗證：

Map<String, String> ns = Collections.singletonMap("ns", "http://www.w3.org/2005/Atom"); mockMvc.perform(get("/handle").accept(MediaType.APPLICATION_XML)).andExpect(xpath("/person/ns:link[@rel=''self'']/@href", ns).string("http://localhost:8080/people"));

注冊過濾器

在配置好?MockMvc?實例后，可以在其后注冊若干個?Filter?實例:

mockMvc = standaloneSetup(new PersonController()).addFilters(new CharacterEncodingFilter()).build();

已注冊的過濾器可以通過?spring-test???包提供的?MockFilterChain?。來調用，并且過濾器鏈的最后一個過濾器會被委托成?DispatcherServlet ?

?基于容器測試和端到端集成測試的區別

前面曾提到過，對Spring MVC的測試是基于?spring-test?模塊提供的實現了Servlet API的mock對象的，并且測試不需要啟動Servlet容器。因此，使用spring test來進行的基于容器測試與使用實際瀏覽器和服務器來進行的端到端測試是有很大差異的。

最簡單的辦法是從空白的?MockHttpServletRequest?入手。不去管你在請求里添加了什么，也不用管這是一個什么樣的請求。讓人驚訝的是，這里面沒有默認的上下文路徑，沒有包含jsessionid?的cookie,沒有跳轉、錯誤以及異步分派請求，因此沒有發生實際的jsp渲染。實際上，“轉發”和“重定向”的鏈接被保存到了MockHttpServletResponse?對象里面，并且可以被斷言。

這意味著如果使用jsp，你可以驗證jsp被哪個請求轉發的，但jsp里的html不會被渲染。換句話說，JSP不會被調用。需要注意，所有不依賴于轉發的渲染技術例如 Thymeleaf, Freemarker, and Velocity 還是會渲染html作為響應體。，對JSON、XML和其它格式的通過?@ResponseBody?@ResponseBody注解標注的方法里返回的數據也一樣。

另外，你也可以考慮使用Spring Boot提供的?@WebIntegrationTest.注解進行端到端的集成測試，參看?Spring Boot reference.

兩種測試方式各有利弊。Spring MVC Test測試方式不能簡單認為是一種規模介于經典單元測試和集成測試之間的測試。確切的說，Spring MVC Test測試方式不是一種經典的單元測試，但和經典的單元測試有點像。例如，你可以通過注入模擬的服務對象到控制器，從而將web層獨立出來，這樣，你就可以通過?DispatcherServlet?，使用項目真實的配置文件來對web層進行單獨的測試。這在操作上，已經和你從DAO的上一層來獨立測試DAO層沒區別了。你也可以使用單例模式啟動，來關注某個Controller在某個時間點的運行情況并且手動提供所需配置，使其運行。

使用Spring MVC Test的另外一個重要區別是，在概念上，該測試是服務端測試，因此你可以檢查諸如哪個控制器被調用，是否某個異常已經被HandlerExceptionResolver處理了，模型的內容以及模型綁定的錯誤等。這使得編寫一個斷言變得很容易，因為此時，服務器端并不是像使用實際的HTTP客戶端進行測試時那樣，是一個黑箱子，是不可見的。

更多服務器端測試例子

框架本身的測試例子里包含許多例子，演示如何使用Spring Test。你可以瀏覽這些示例，獲得更多靈感。同樣，在spring-mvc-showcase里面也有許多完全基于spring test的測試例子。

14.6.2?HtmlUnit 集成

Spring支持MockMvc和HtmlUnit.集成。它能簡化使用html執行一個端到端測試的過程。集成之后，開發者可以:

• 使用HtmlUnit,?WebDriver和?Geb?等工具來測試html網頁將變得很簡單，不需要再部署到服務器。
• 可以測試頁面內的javascript代碼
• 使用mock服務配置測試，提高測試速度
• 復用端到端測試和基于容器測試的邏輯。

	MockMvc?works with templating technologies that do not rely on a Servlet Container (e.g., Thymeleaf, Freemarker, Velocity, etc.), but it does not work with JSPs since they rely on the Servlet Container.

為什么使用 HtmlUnit 集成?

你可能會想，為什么我需要用它？答案是，從一個最簡單的程序里可以找到答案。假設你有一個Spring MVC網站程序，這個程序有一個?Message?對象，對象有CURD等操作。這個程序可以分頁顯示所有的消息，你將如何測試它？

使用Spring MVC Test，假如我們是直接創建?Message對象的話，這將是很簡單的事。

MockHttpServletRequestBuilder createMessage = post("/messages/").param("summary", "Spring Rocks").param("text", "In case you didn't know, Spring Rocks!");mockMvc.perform(createMessage).andExpect(status().is3xxRedirection()).andExpect(redirectedUrl("/messages/123"));

但是，假如Message對象是從表單里創建的，該如何測試？舉個例子，假如我們的有表單如下：

<form id="messageForm" action="/messages/" method="post"><div class="pull-right"><a href="/messages/">Messages</a></div><label for="summary">Summary</label><input type="text" class="required" id="summary" name="summary" value="" /><label for="text">Message</label><textarea id="text" name="text"></textarea><div class="form-actions"><input type="submit" value="Create" /></div> </form>

如何保證表單會生成一個正確的請求來創建Message對象？有人會天真的使用下面的方法：

mockMvc.perform(get("/messages/form")).andExpect(xpath("//input[@name='summary']").exists()).andExpect(xpath("//textarea[@name='text']").exists());

這個測試有明顯的缺陷。假如我們更新了Controller，將參數名?text修改成message?。我們的測試還會照常發送請求，即使表單沒有同步更新。對此，我們可以使用拼接語句的方法，如下：

String summaryParamName = "summary"; String textParamName = "text"; mockMvc.perform(get("/messages/form")).andExpect(xpath("//input[@name='" + summaryParamName + "']").exists()).andExpect(xpath("//textarea[@name='" + textParamName + "']").exists());MockHttpServletRequestBuilder createMessage = post("/messages/").param(summaryParamName, "Spring Rocks").param(textParamName, "In case you didn't know, Spring Rocks!");mockMvc.perform(createMessage).andExpect(status().is3xxRedirection()).andExpect(redirectedUrl("/messages/123"));

這會減少發送不正確的請求的風險，但還是存在下列問題：

• 假如頁面包含多個表單該如何測試？確實，我們可以通過更新我們的xpath表達式來解決，但這回會變得復雜得多了，我們需要考慮更多因素（例如：表單域的類型是否正確？表單域是否可用）

• ?另一個問題是，我們要付出雙倍的勞動。我們首先要驗證視圖，然后提交視圖附帶剛剛驗證過的參數。理論上這個可以一次完成。

• 最后，這里還有一些我們沒法考慮得事情。例如，假如我們還想測試表單的Javascript數據校驗代碼怎么辦？

總的來說問題是，測試網頁不是針對單一的交互。相反的，它摻雜了用戶如何與網頁交互以及網頁如何和其它資源交互。舉個例子，表單視圖的顯示結果是用來給用戶輸入以創建Message對象。更有甚者，我們的表單可能潛在使用了其它可能影響頁面行為的資源，例如javascript數據校驗。

使用端到端集成測試來解救?

為解決上節所述問題，我們可以使用端到端的集成測試，但其同樣有缺陷。考慮消息列表頁，其可以通過分頁瀏覽多個消息。我們需要測試下列方面：

• 當消息列表為空時，頁面是否會顯示一個提示信息，告訴用戶當前沒有結果可展示？

• 頁面是否正確顯示一條消息？

• 分頁瀏覽是否正確？

運行這些測試之前，我們要確保我們的數據庫已經包含正確的消息數據了。這有導致了一系列其它挑戰。

• 確認數據庫里的消息數據正確無誤是一個乏味而繁瑣的過程，要考慮外鍵約束。

• 測試會變得很慢，因為每次測試都要確認數據庫無誤。

• 因為數據庫需要置于某個特定狀態才能進行測試，所以多個測試不能并行的進行。
• 對自動生成的id、timesstamp很難進行斷言

這些挑戰并不意味著我們是要禁止所有的端到端測試，而是，通過重構復雜的測試，使用執行更快，更可靠，并且沒有邊際效應的模擬服務，我們能夠減少端到端測試的次數。之后我們可以實施少數幾次真正的端到端集成測試，只用來驗證簡單的工作流以確保多個頁面協同工作正常。

使用HtmlUnit集成測試

那么如何達到既能測試頁面交互又能保持良好的測試性能呢？答案是：“把MockMvc和HtmlUnit集成起來”。

HtmlUnit集成選項

有多種方式可集成MockMvc?和HtmlUnit：

• MockMvc加HtmlUnit:如果你想使用原生的HtmlUnit，那就用這種方法。

• MockMvc加WebDriver：這種方式可以減少開發量，重用集成和端到端測試的代碼。
• MockMvc加 Geb：假如你想在Groovy下測試，可以使用這種方式，同樣減少開發量，重用集成和端到端測試的代碼。

MockMvc加?HtmlUnit?方式

本節介紹集成?MockMvc?與HtmlUnit。假如你想要使用原生的HtmlUnit庫就可以使用這種方式。

集成MockMvc和HtmlUnit的啟動

首先，你要將依賴?net.sourceforge.htmlunit:htmlunit包含進來。為了在Apache HttpComponents4.5+上使用，你的HtmlUnit版本至少要2.18及以上。

使用?MockMvcWebClientBuilder?，可以很容易的創建一個集成了?MockMvc??的HtmlUnit??WebClient?對象，如下所示：

@Autowired WebApplicationContext context;WebClient webClient;@Before public void setup() {webClient = MockMvcWebClientBuilder.webAppContextSetup(context).build(); }

	This is a simple example of using?MockMvcWebClientBuilder. For advanced usage see?the section called “Advanced MockMvcWebClientBuilder”

上述代碼可以確保任何指向?localhost?的URL會定向到?MockMvc?實例來處理，而不會發生真實的HTTP連接。任何其它請求還是使用真實網絡連接，與普通瀏覽器一樣。這樣，即使使用了CDN，測試起來也很簡單。

集成MockMvc和 HtmlUnit的用法

現在，我們可以如使用普通瀏覽器一樣使用HtmlUnit，但不需要部署應用到服務器。例如，我們可以用如下代碼，請求創建創新消息的視圖：

HtmlPage createMsgFormPage = webClient.getPage("http://localhost/messages/form");

	The default context path is?"". Alternatively, we can specify the context path as illustrated in?the section called “Advanced MockMvcWebClientBuilder”.

一旦獲得?HtmlPage，?HtmlPage的引用，我們就可以填充表單然后提交，就可以創建一條消息。

HtmlForm form = createMsgFormPage.getHtmlElementById("messageForm"); HtmlTextInput summaryInput = createMsgFormPage.getHtmlElementById("summary"); summaryInput.setValueAttribute("Spring Rocks"); HtmlTextArea textInput = createMsgFormPage.getHtmlElementById("text"); textInput.setText("In case you didn't know, Spring Rocks!"); HtmlSubmitInput submit = form.getOneHtmlElementByAttribute("input", "type", "submit"); HtmlPage newMessagePage = submit.click();

最后，我們可以檢驗新的消息是否創建成功。下面的斷言使用了AssertJ?庫。

assertThat(newMessagePage.getUrl().toString()).endsWith("/messages/123"); String id = newMessagePage.getHtmlElementById("id").getTextContent(); assertThat(id).isEqualTo("123"); String summary = newMessagePage.getHtmlElementById("summary").getTextContent(); assertThat(summary).isEqualTo("Spring Rocks"); String text = newMessagePage.getHtmlElementById("text").getTextContent(); assertThat(text).isEqualTo("In case you didn't know, Spring Rocks!");

這樣做會在血多方面提升我們的MockMvc測試。首先，我們不需要再先顯式驗證表單然后才能創建請求，而且這個請求只是看起來和表單請求一樣而已。現在我們只需要請求表單，填充表單，然后提交，顯著減少了額外工作。

另一個重要因素是，HtmlUnit使用Mozilla Rhino engine來校驗Javascript，這意味著我們也可以測試頁面包含的Javascript代碼。.

更多HtmlUnit的使用方法請參看HtmlUnit參考文檔。

MockMvcWebClientBuilder高級用法

在前面的例子中，我們盡可能用最簡單的方法使用?MockMvcWebClientBuilder?創建一個?WebClient?，基于Spring TestContext框架加載的?WebApplicationContext。下面重復這個方法：

@Autowired WebApplicationContext context;WebClient webClient;@Before public void setup() {webClient = MockMvcWebClientBuilder.webAppContextSetup(context).build(); }

我們還可以指定更多配置選項。

WebClient webClient;@Before public void setup() {webClient = MockMvcWebClientBuilder// demonstrates applying a MockMvcConfigurer (Spring Security).webAppContextSetup(context, springSecurity())// for illustration only - defaults to "".contextPath("")// By default MockMvc is used for localhost only;// the following will use MockMvc for example.com and example.org as well.useMockMvcForHosts("example.com","example.org").build(); }

作為替代，我們也可使用相同的啟動過程，通過配置一個獨立的?MockMvc?實例，并且應用到?MockMvcWebClientBuilder?中，如下：

MockMvc mockMvc = MockMvcBuilders.webAppContextSetup(context).apply(springSecurity()).build();webClient = MockMvcWebClientBuilder.mockMvcSetup(mockMvc)// for illustration only - defaults to "".contextPath("")// By default MockMvc is used for localhost only;// the following will use MockMvc for example.com and example.org as well.useMockMvcForHosts("example.com","example.org").build();

配置起來是比較冗長的，但是用?MockMvc?實例創建出?WebClient?之后，我們就擁有了?MockMvc?的全部能力。

	For additional information on creating a?MockMvc?instance refer to?the section called “Setup Options”.

MockMvc 加WebDriver方式

上一節我們知道了如何將MockMvc?和HtmlUint結合起來。這一節，我們將利用另外一些?WebDriver定義的概念來使測試變得更容易。

為何要使用WebDriver 與MockMvc集成?

我們已經使用了HtmlUnit 和?MockMvc，為什么還要去使用?WebDriver呢？這是因為?WebDriver提供了一套非常優雅的API，使我們能夠很容易的組織代碼。為了明白這點，我們來看個例子。

	Despite being a part of?Selenium, WebDriver does not require a Selenium Server to run your tests.

假如我們現在需要確認消息已經被正確的創建，測試的過程包括找到HTML表單的input元素，填充，然后編寫多個斷言。

這種方法會導致數不勝數的，彼此獨立的測試，因為我們也要測試出錯情況。例如，要確認如果只是填充表單的一部分的話，會拋出錯誤，而填充整個表單，則新創建的表單稍后會顯示出來。

假如表單里有一個名為"summary"的域，像那么下面的代碼在我們測試中可能會經常出現：

HtmlTextInput summaryInput = currentPage.getHtmlElementById("summary"); summaryInput.setValueAttribute(summary);

假如將?id?設為"smmry"會發生什么？這會迫使我們修改所有測試方法，來適應這次更改。這違反了DRY原則，因此，我們應該將這些相同的代碼提取到一個方法中。

public HtmlPage createMessage(HtmlPage currentPage, String summary, String text) {setSummary(currentPage, summary);// ... }public void setSummary(HtmlPage currentPage, String summary) {HtmlTextInput summaryInput = currentPage.getHtmlElementById("summary");summaryInput.setValueAttribute(summary); }

這就保證我們在改變UI的時候無需更新所有的測試方法。

還可再進一步的，把這些代碼邏輯放入當前網頁的?HtmlPage?對象里去。

public class CreateMessagePage {final HtmlPage currentPage;final HtmlTextInput summaryInput;final HtmlSubmitInput submit;public CreateMessagePage(HtmlPage currentPage) {this.currentPage = currentPage;this.summaryInput = currentPage.getHtmlElementById("summary");this.submit = currentPage.getHtmlElementById("submit");}public <T> T createMessage(String summary, String text) throws Exception {setSummary(summary);HtmlPage result = submit.click();boolean error = CreateMessagePage.at(result);return (T) (error ? new CreateMessagePage(result) : new ViewMessagePage(result));}public void setSummary(String summary) throws Exception {summaryInput.setValueAttribute(summary);}public static boolean at(HtmlPage page) {return "Create Message".equals(page.getTitleText());} }

最初，這個模式被熟知為“頁面對象模式”。我們可以在使用HtmlUnit框架時使用該模式，然而WebDriver框架提供了一些工具，使得該模式更容易編寫實現。下一節我們將探討該模式。

集成MockMvc 和 WebDriver的啟動

要在Spring MVC測試框架里使用WebDriver框架，需先加入依賴org.seleniumhq.selenium:selenium-htmlunit-driver.到項目中。

我們可以很容易的使用?MockMvcHtmlUnitDriverBuilder?集成?WebDriver?和?MockMvc?，代碼如下：

@Autowired WebApplicationContext context;WebDriver driver;@Before public void setup() {driver = MockMvcHtmlUnitDriverBuilder.webAppContextSetup(context).build(); }

	This is a simple example of using?MockMvcHtmlUnitDriverBuilder. For more advanced usage, refer to?the section called “Advanced MockMvcHtmlUnitDriverBuilder”

上述代碼可以確保任何指向?localhost?的URL會定向到?MockMvc?實例來處理，而不會發生真實的HTTP連接。任何其它請求還是使用真實網絡連接，與普通瀏覽器一樣。這樣，即使使用了CDN，測試起來也很簡單。

集成MockMvc 和 WebDriver的用法

現在，我們可以如使用普通瀏覽器一樣使用WebDriver，但不需要部署應用到服務器。例如，我們可以用如下代碼，請求創建創新消息的視圖：

CreateMessagePage page = CreateMessagePage.to(driver);

我們可以填充表單然后提交以創建一條新的消息。

ViewMessagePage viewMessagePage =page.createMessage(ViewMessagePage.class, expectedSummary, expectedText);

這個測試使用了頁面對象模式，改進了之前使用HtmlUnit的測試方法。正如在“為何要使用WebDriver 與MockMvc集成”章節里提到的，我們可以在集成HtmlUnit框架后使用頁面對象模式，但在WebDriver里使用將會更容易。下面請看新的?CreateMessagePage?類的實現：

public class CreateMessagePageextends AbstractPage { private WebElement summary;private WebElement text;@FindBy(css = "input[type=submit]")private WebElement submit;public CreateMessagePage(WebDriver driver) {super(driver);}public <T> T createMessage(Class<T> resultPage, String summary, String details) {this.summary.sendKeys(summary);this.text.sendKeys(details);this.submit.click();return PageFactory.initElements(driver, resultPage);}public static CreateMessagePage to(WebDriver driver) {driver.get("http://localhost:9990/mail/messages/form");return PageFactory.initElements(driver, CreateMessagePage.class);} }

	你首先要注意的是，CreateMessagePage?類繼承自AbstractPage。我們不會詳述AbstractPage類的細節，但總的來說，它包含了所有頁面的公共方法。就好像，假如應用程序里有一個導航條，或者全局錯誤信息之類，可以把這些邏輯可以放到一個共享的地方一樣。
	另外一個值得注意的地方是，每個我們感興趣的html部位，都有一個成員變量與之對應。WebElement.WebDriver類型的頁面工廠類通過自動解析每個網頁元素，允許我們移除大量HtmlUnit版本的CreateMessagePage?方法里的代碼。PageFactory#initElements(WebDriver,Class<T>)方法通過成員變量名稱，查找網頁內所有元素的id和name，自動解析每個網頁元素.
	我們可以使用?@FindBy?注解覆蓋默認的查找方式。我們的例子演示如何使用?@FindBy?注解，通過css選擇器input[type=submit]，來查找提交按鈕。

最后，我們可以檢驗新消息已經創建成功。下面的斷言使用了FEST assertion庫。

assertThat(viewMessagePage.getMessage()).isEqualTo(expectedMessage); assertThat(viewMessagePage.getSuccess()).isEqualTo("Successfully created a new message");

可以看見，?ViewMessagePage?實例允許我們和自定義域模型打交道。例如，它公開了返回?Message?對象的方法。

public Message getMessage() throws ParseException {Message message = new Message();message.setId(getId());message.setCreated(getCreated());message.setSummary(getSummary());message.setText(getText());return message; }

然后我們就可以在斷言中使用該域對象。

最后，測試完后，別忘了關閉?WebDriver?的實例。
@After public void destroy() {if (driver != null) {driver.close();} }

更過使用WebDriver框架的信息，請參看“WebDriver參考文檔”。

?MockMvcHtmlUnitDriverBuilder高級用法

在前面的例子中，我們盡可能用最簡單的方法使用?MockMvcHtmlUnitDriverBuilder?：創建一個?WebDriver?對象，基于Spring TestContext框架加載的?WebApplicationContext。下面重復這個方法：

@Autowired WebApplicationContext context;WebDriver driver;@Before public void setup() {driver = MockMvcHtmlUnitDriverBuilder.webAppContextSetup(context).build(); }

我們還可以指定更多配置選項。

WebDriver driver;@Before public void setup() {driver = MockMvcHtmlUnitDriverBuilder// demonstrates applying a MockMvcConfigurer (Spring Security).webAppContextSetup(context, springSecurity())// for illustration only - defaults to "".contextPath("")// By default MockMvc is used for localhost only;// the following will use MockMvc for example.com and example.org as well.useMockMvcForHosts("example.com","example.org").build(); }

作為替代，我們也可使用相同的啟動過程，通過配置一個獨立的?MockMvc?實例，并且應用到?MockMvcHtmlUnitDriverBuilder?中，如下：

MockMvc mockMvc = MockMvcBuilders.webAppContextSetup(context).apply(springSecurity()).build();driver = MockMvcHtmlUnitDriverBuilder.mockMvcSetup(mockMvc)// for illustration only - defaults to "".contextPath("")// By default MockMvc is used for localhost only;// the following will use MockMvc for example.com and example.org as well.useMockMvcForHosts("example.com","example.org").build();

配置起來是比較冗長的，但是用?MockMvc?實例創建出?WebDriver?之后，我們就擁有了?MockMvc?的全部能力。

	For additional information on creating a?MockMvc?instance refer to?the section called “Setup Options”.

MockMvc 加 Geb方式

上一個章節，我們已經知道如何使用?MockMvc?和?WebDriver，本章節，我們將使用Geb來使我們的測試更Groovy化。

為何要集成 Geb 與MockMvc?

Geb框架是有WebDriver作為后盾的，因此它的優點和WebDriver是一樣的。Geb框架處理掉了樣板代碼，使得測試更簡潔，更簡單。

集成MockMvc和Geb方式啟動

通過如下使用了?MockMvc?的?WebDriver?對象，我們可以很容易的實例化一個Geb?框架的??Browser?對象。

def setup() {browser.driver = MockMvcHtmlUnitDriverBuilder.webAppContextSetup(context).build() }

	This is a simple example of using?MockMvcHtmlUnitDriverBuilder. For more advanced usage, refer to?the section called “Advanced MockMvcHtmlUnitDriverBuilder”

上述代碼可以確保任何指向?localhost?的URL會定向到?MockMvc?實例來處理，而不會發生真實的HTTP連接。任何其它請求還是使用真實網絡連接，與普通瀏覽器一樣。這樣，即使使用了CDN，測試起來也很簡單。

集成MockMvc和Geb的用法

現在，我們可以如使用普通瀏覽器一樣使用Geb，但不需要部署應用到服務器。例如，我們可以用如下代碼，請求創建創新消息的視圖：

to CreateMessagePage

我們可以填充表單然后提交以創建一條新的消息。

when: form.summary = expectedSummary form.text = expectedMessage submit.click(ViewMessagePage)

任何對不存在的方法的調用或對不存在的屬性獲取、引用，都會轉發給當前頁面對象。這可以減少很多存在于直接使用WebDriver時的樣板代碼。

和直接使用WebDriver相比，這個測試使用了頁面對象模式，改進了之前使用HtmlUnit的測試方法。正如之前提到的，我們可以在集成HtmlUnit框架或WebDriver框架后使用頁面對象模式，但在Geb里使用將會更容易。下面請看基于Groovy 的新的?CreateMessagePage?類的實現：
class CreateMessagePage extends Page {static url = 'messages/form'static at = { assert title == 'Messages : Create'; true }static content = {submit { $('input[type=submit]') }form { $('form') }errors(required:false) { $('label.error, .alert-error')?.text() }} }

你首先要注意的是，?CreateMessagePage?類繼承自?Page。我們不會詳述?Page類的細節，但總的來說，它包含了所有頁面的公共方法。其次，我們定義了一個訪問該頁面的URL,所以我們可以通過如下方式找到頁面。

to CreateMessagePage

我們還定義了?at?代碼塊，它可以判斷我們當前頁面是否是某個指定的頁面。假如我們訪問的是正確的頁面，它就會返回?true?。這也是為何我們可以在下面使用斷言來斷言我們是否訪問了正確的頁面。

then: at CreateMessagePage errors.contains('This field is required.')

	We use an assertion in the closure, so that we can determine where things went wrong if we were at the wrong page.

然后我們創建一個?content?代碼塊，用來指定頁面內所有感興趣的區域。我們可以使用jQuery-ish Navigator API?來選擇我們感興趣的內容。

最后，我們可以檢驗新消息是否創建成功。
then: at ViewMessagePage success == 'Successfully created a new message' id date summary == expectedSummary message == expectedMessage

更多關于如何最大化的使用Geb，請參考Geb用戶手冊一書。

14.6.3?Client-Side REST Tests

Client-side tests are for code using the?RestTemplate. The goal is to define expected requests and provide "stub" responses:

RestTemplate restTemplate = new RestTemplate();MockRestServiceServer mockServer = MockRestServiceServer.createServer(restTemplate); mockServer.expect(requestTo("/greeting")).andRespond(withSuccess("Hello world", MediaType.TEXT_PLAIN));// use RestTemplate ...mockServer.verify();

In the above example,?MockRestServiceServer?—?the central class for client-side REST tests?—?configures the?RestTemplate?with a customClientHttpRequestFactory?that asserts actual requests against expectations and returns "stub" responses. In this case we expect a single request to "/greeting" and want to return a 200 response with "text/plain" content. We could define as many additional requests and stub responses as necessary.

Once expected requests and stub responses have been defined, the?RestTemplate?can be used in client-side code as usual. At the end of the testsmockServer.verify()?can be used to verify that all expected requests were performed.

Static Imports

Just like with server-side tests, the fluent API for client-side tests requires a few static imports. Those are easy to find by searching?"MockRest*". Eclipse users should add"MockRestRequestMatchers.*"?and?"MockRestResponseCreators.*"?as "favorite static members" in the Eclipse preferences under?Java → Editor → Content Assist → Favorites. That allows using content assist after typing the first character of the static method name. Other IDEs (e.g. IntelliJ) may not require any additional configuration. Just check the support for code completion on static members.

Further Examples of Client-side REST Tests

Spring MVC Test’s own tests include?example tests?of client-side REST tests.

14.7?PetClinic Example

The PetClinic application, available on?GitHub, illustrates several features of the?Spring TestContext Framework?in a JUnit environment. Most test functionality is included in theAbstractClinicTests, for which a partial listing is shown below:

import static org.junit.Assert.assertEquals; // import ...@ContextConfiguration public abstract class AbstractClinicTests extends AbstractTransactionalJUnit4SpringContextTests {@Autowiredprotected Clinic clinic;@Testpublic void getVets() {Collection<Vet> vets = this.clinic.getVets();assertEquals("JDBC query must show the same number of vets",super.countRowsInTable("VETS"), vets.size());Vet v1 = EntityUtils.getById(vets, Vet.class, 2);assertEquals("Leary", v1.getLastName());assertEquals(1, v1.getNrOfSpecialties());assertEquals("radiology", (v1.getSpecialties().get(0)).getName());// ...}// ... }

Notes:

• This test case extends the?AbstractTransactionalJUnit4SpringContextTests?class, from which it inherits configuration for Dependency Injection (through theDependencyInjectionTestExecutionListener) and transactional behavior (through the?TransactionalTestExecutionListener).
• The?clinic?instance variable?—?the application object being tested?—?is set by Dependency Injection through?@Autowired?semantics.
• The?getVets()?method illustrates how you can use the inherited?countRowsInTable()?method to easily verify the number of rows in a given table, thus verifying correct behavior of the application code being tested. This allows for stronger tests and lessens dependency on the exact test data. For example, you can add additional rows in the database without breaking tests.
• Like many integration tests that use a database, most of the tests in?AbstractClinicTests?depend on a minimum amount of data already in the database before the test cases run. Alternatively, you might choose to populate the database within the test fixture set up of your test cases?—?again, within the same transaction as the tests.

The PetClinic application supports three data access technologies: JDBC, Hibernate, and JPA. By declaring?@ContextConfiguration?without any specific resource locations, the?AbstractClinicTests?class will have its application context loaded from the default location,?AbstractClinicTests-context.xml, which declares a common?DataSource. Subclasses specify additional context locations that must declare a?PlatformTransactionManager?and a concrete implementation of?Clinic.

For example, the Hibernate implementation of the PetClinic tests contains the following implementation. For this example,?HibernateClinicTests?does not contain a single line of code: we only need to declare?@ContextConfiguration, and the tests are inherited from?AbstractClinicTests. Because?@ContextConfiguration?is declared without any specific resource locations, the?Spring TestContext Framework?loads an application context from all the beans defined inAbstractClinicTests-context.xml?(i.e., the inherited locations) and?HibernateClinicTests-context.xml, with?HibernateClinicTests-context.xmlpossibly overriding beans defined in?AbstractClinicTests-context.xml.

@ContextConfiguration public class HibernateClinicTests extends AbstractClinicTests { }

In a large-scale application, the Spring configuration is often split across multiple files. Consequently, configuration locations are typically specified in a common base class for all application-specific integration tests. Such a base class may also add useful instance variables?—?populated by Dependency Injection, naturally?—?such as aSessionFactory?in the case of an application using Hibernate.

As far as possible, you should have exactly the same Spring configuration files in your integration tests as in the deployed environment. One likely point of difference concerns database connection pooling and transaction infrastructure. If you are deploying to a full-blown application server, you will probably use its connection pool (available through JNDI) and JTA implementation. Thus in production you will use a?JndiObjectFactoryBean?or?<jee:jndi-lookup>?for the?DataSource?andJtaTransactionManager. JNDI and JTA will not be available in out-of-container integration tests, so you should use a combination like the Commons DBCPBasicDataSource?and?DataSourceTransactionManager?or?HibernateTransactionManager?for them. You can factor out this variant behavior into a single XML file, having the choice between application server and a 'local' configuration separated from all other configuration, which will not vary between the test and production environments. In addition, it is advisable to use properties files for connection settings. See the PetClinic application for an example.

總結

以上是生活随笔為你收集整理的14.6 Spring MVC 测试框架（翻译）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。