Mock測驗你的Spring MVC介面-有解無憂

1. 前言

在Java開發中接觸的開發者大多數不太注重對介面的測驗，結果在聯調對接中出現各種問題，也有的使用Postman等工具進行測驗，雖然在使用上沒有什么問題，如果介面增加了權限測驗起來就比較惡心了，所以建議在單元測驗中測驗介面，保證在交付前先自測介面的健壯性，今天就來分享一下胖哥在開發中是如何對Spring MVC介面進行測驗的，

在開始前請務必確認添加了Spring Boot Test相關的組件，在最新的版本中應該包含以下依賴：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
    <exclusions>
        <exclusion>
            <groupId>org.junit.vintage</groupId>
            <artifactId>junit-vintage-engine</artifactId>
        </exclusion>
    </exclusions>
</dependency>

本文是在Spring Boot 2.3.4.RELEASE下進行的，

2. 單獨測驗控制層

如果我們只需要對控制層介面(Controller)進行測驗，且該介面不依賴@Service、@Component等注解宣告的Spring Bean時，可以借助@WebMvcTest來啟用只針對Web控制層的測驗，例如

@WebMvcTest
class CustomSpringInjectApplicationTests {
    @Autowired
    MockMvc mockMvc;

    @SneakyThrows
    @Test
    void contextLoads() {
        mockMvc.perform(MockMvcRequestBuilders.get("/foo/map"))
                .andExpect(ResultMatcher.matchAll(status().isOk(),
                        content().contentType(MediaType.APPLICATION_JSON),
                        jsonPath("$.test", Is.is("hello"))))
                .andDo(MockMvcResultHandlers.print());
    }

}

這種方式要快的多，它只加載了應用程式的一小部分，但是如果你涉及到服務層這種方式是不湊效的，我們就需要另一種方式了，

3. 整體測驗

大多數Spring Boot下的介面測驗是整體而又全面的測驗，涉及到控制層、服務層、持久層等方方面面，所以需要加載比較完整的Spring Boot背景關系，這時我們可以這樣做，宣告一個抽象的測驗基類：

package cn.felord.custom;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.web.servlet.MockMvc;


/**
 * 測驗基類，
 * @author felord.cn
 */
@SpringBootTest
@AutoConfigureMockMvc
abstract class CustomSpringInjectApplicationTests {
    /**
     * The Mock mvc.
     */
    @Autowired
    MockMvc mockMvc;
    // 其它公共依賴和處理方法 
}

只有當@AutoConfigureMockMvc存在時MockMvc才會被注入Spring IoC，

然后針對具體的控制層進行如下測驗代碼的撰寫：

package cn.felord.custom;

import lombok.SneakyThrows;
import org.hamcrest.core.Is;
import org.junit.jupiter.api.Test;
import org.springframework.http.MediaType;
import org.springframework.test.web.servlet.ResultMatcher;
import org.springframework.test.web.servlet.request.MockMvcRequestBuilders;
import org.springframework.test.web.servlet.result.MockMvcResultHandlers;

import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;

/**
 * 測驗FooController.
 *
 * @author felord.cn
 */
public class FooTests extends CustomSpringInjectApplicationTests {
    /**
     * /foo/map介面測驗.
     */
    @SneakyThrows
    @Test
    void contextLoads() {
        mockMvc.perform(MockMvcRequestBuilders.get("/foo/map"))
                .andExpect(ResultMatcher.matchAll(status().isOk(),
                        content().contentType(MediaType.APPLICATION_JSON),
                        jsonPath("$.test", Is.is("bar"))))
                .andDo(MockMvcResultHandlers.print());
    }
}

4. MockMvc測驗

集成測驗時，希望能夠通過輸入URL對Controller進行測驗，如果通過啟動服務器，建立http client進行測驗，這樣會使得測驗變得很麻煩，比如，啟動速度慢，測驗驗證不方便，依賴網路環境等，為了可以對Controller進行測驗就引入了MockMvc，

MockMvc實作了對Http請求的模擬，能夠直接使用網路的形式，轉換到Controller的呼叫，這樣可以使得測驗速度快、不依賴網路環境，而且提供了一套驗證的工具，這樣可以使得請求的驗證統一而且很方便，接下來我們來一步步構造一個測驗的模擬請求，假設我們存在一個下面這樣的介面：

@RestController
@RequestMapping("/foo")
public class FooController {
    @Autowired
    private MyBean myBean;

    @GetMapping("/user")
    public Map<String, String> bar(@RequestHeader("Api-Version") String apiVersion, User user) {
        Map<String, String> map = new HashMap<>();
        map.put("test", myBean.bar());
        map.put("version", apiVersion);
        map.put("username", user.getName());
        //todo your business
        return map;
    }
}

引數設定為name=felord.cn&age=18，那么對應的HTTP報文是這樣的：

GET /foo/user?name=felord.cn&age=18 HTTP/1.1
Host: localhost:8888
Api-Version: v1

可以預見的回傳值為：

{
    "test": "bar",
    "version": "v1",
    "username": "felord.cn"
}

事實上對介面的測驗可以分為以下幾步，

構建請求

構建請求由MockMvcRequestBuilders負責，他提供了請求方法（Method），請求頭(Header)，請求體(Body)，引數（Parameters），會話（Session）等所有請求的屬性構建，/foo/user介面的請求可以轉換為：

MockMvcRequestBuilders.get("/foo/user")
                .param("name", "felord.cn")
                .param("age", "18")
                .header("Api-Version", "v1")

執行Mock請求

然后由MockMvc執行Mock請求：

mockMvc.perform(MockMvcRequestBuilders.get("/foo/user")
                .param("name", "felord.cn")
                .param("age", "18")
                .header("Api-Version", "v1"))

對結果進行處理

請求結果被封裝到ResultActions物件中，它封裝了多種讓我們對Mock請求結果進行處理的方法，

對結果進行預期期望

ResultActions#andExpect(ResultMatcher matcher)方法負責對回應的結果的進行預期期望，看看是否符合測驗的期望值，引數ResultMatcher負責從回應物件中提取我們需要期望的部位進行預期比對，

假如我們期望介面/foo/user回傳的是JSON，并且HTTP狀態為200，同時回應體包含了version=v1的值，我們應該這么宣告：

   ResultMatcher.matchAll(MockMvcResultMatchers.status().isOk(),
                MockMvcResultMatchers.content().contentType(MediaType.APPLICATION_JSON),
                MockMvcResultMatchers.jsonPath("$.version", Is.is("v1")));

JsonPath是一個強大的JSON決議類別庫，請通過其專案倉庫https://github.com/json-path/JsonPath了解，

對回應進行處理

ResultActions#andDo(ResultHandler handler)方法負責對整個請求/回應進行列印或者log輸出、流輸出，由MockMvcResultHandlers工具類提供這些方法，我們可以通過以上三種途徑來查看請求回應的細節，

例如/foo/user介面：

MockHttpServletRequest:
      HTTP Method = GET
      Request URI = /foo/user
       Parameters = {name=[felord.cn], age=[18]}
          Headers = [Api-Version:"v1"]
             Body = null
    Session Attrs = {}

Handler:
             Type = cn.felord.xbean.config.FooController
           Method = cn.felord.xbean.config.FooController#urlEncode(String, Params)

Async:
    Async started = false
     Async result = null

Resolved Exception:
             Type = null

ModelAndView:
        View name = null
             View = null
            Model = null

FlashMap:
       Attributes = null

MockHttpServletResponse:
           Status = 200
    Error message = null
          Headers = [Content-Type:"application/json"]
     Content type = application/json
             Body = {"test":"bar","version":"v1","username":"felord.cn"}
    Forwarded URL = null
   Redirected URL = null
          Cookies = []

獲取回傳結果

如果你希望進一步處理回應的結果，也可以通過ResultActions#andReturn()拿到MvcResult 型別的結果進行進一步的處理，

完整的測驗程序

通常andExpect是我們必然會選擇的，而andDo和andReturn在某些場景下會有用，它們兩個是可選的，我們把上面的連在一起，

@Autowired
MockMvc mockMvc;

@SneakyThrows
@Test
void contextLoads() {

     mockMvc.perform(MockMvcRequestBuilders.get("/foo/user")
            .param("name", "felord.cn")
            .param("age", "18")
            .header("Api-Version", "v1"))
            .andExpect(ResultMatcher.matchAll(status().isOk(),
                    content().contentType(MediaType.APPLICATION_JSON),
                    jsonPath("$.version", Is.is("v1"))))
            .andDo(MockMvcResultHandlers.print());
            
}

這種流式的介面單元測驗從語意上看也是比較好理解的，你可以使用各種斷言、正例、反例測驗你的介面，最終讓你的介面更加健壯，

5. 總結

一旦你熟練了這種方式，你撰寫的介面將更加具有權威性而不會再漏洞百出，甚至有時候你也可以使用Mock來設計介面，使之更加貼合業務，所以CRUD不是完全沒有技術含量，高質量高效率的CRUD往往需要這種工程化的單元測驗來支撐，好了今天的分享就到這里，我是：碼農小胖哥，多多關注，多多支持，

關注公眾號：Felordcn 獲取更多資訊

個人博客：https://felord.cn

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/173519.html

標籤：其他

上一篇：Celery異步分布佇列

下一篇：習題7-3 判斷上三角矩陣