[[384327]]

本文轉(zhuǎn)載自微信公眾號「愛笑的架構(gòu)師」，作者雷架。轉(zhuǎn)載本文請聯(lián)系愛笑的架構(gòu)師公眾號。  

初識mock

作為一個動詞，mock是模擬、模仿的意思;作為一個名詞，mock是能夠模仿真實對象行為的模擬對象。

在軟件測試中，mock所模擬的對象是什么呢?

它一定不是我們所測試的對象，而是 SUT 的依賴(dependency)。換句話說，mock 的作用是模擬 SUT 依賴對象的行為。

測試的對象一般稱之為SUT(Software Under Test)

文字不好理解，我們畫個圖，如下圖所示，被測試對象是 A，A 依賴的是B，B 依賴的是 C。而我們要 mock 的是 B 的行為。圖中 A 就是 SUT。

為什么需要模擬 B 的行為呢?

• (1)提高 A 的測試覆蓋率。A 依賴 B，本質(zhì)上依賴的是 B 的返回結(jié)果，也就是說 B 的返回結(jié)果會影響 A 的行為。通過 mock B 我們可以構(gòu)造各種正常和異常的來自 B 的返回結(jié)果，從而更充分測試 A 的行為。
• (2)避免 B 的因素從而對 A 產(chǎn)生影響。依賴真實的 B 去測試 A 可能有很多問題：B 的開發(fā)沒有完成時無法測試 A;B 有阻塞性bug 時無法測試 A;B 的依賴 C 有阻塞性 bug 時無法測試 A;
• (3)提高 A 的測試效率。B 的真實行為可能很慢，而 B 的模擬行為是非常快的，因此可以加快 A 的測試執(zhí)行速度。

mock 種族

常見的 mock 類型如下圖所示：

從下往上依次解釋一下：

• (1)方法級別 mock：mock 的對象是一個函數(shù)調(diào)用，例如獲取系統(tǒng)環(huán)境變量。
• (2)類級別 mock：mock 的對象是一個類，例如一個 HTTP server。
• (3)接口級別 mock：mock 的對象是一個 API 接口。
• (4)服務(wù)級別 mock：mock 的對象是整個服務(wù)。比如前端工程師自測試時，可以講后端整個服務(wù)都 mock 掉，這其實等同于將后端的所有接口都 mock。

接口mock注入的五種方式

在使用 mock 進行接口測試時，一般要做兩件事情，即打樁和調(diào)樁。

其實打樁就是創(chuàng)建mock 樁，指定 API 請求內(nèi)容及其映射的 mock 響應(yīng)內(nèi)容;所謂調(diào)樁就是被測服務(wù)來請求 mock 樁并接收 mock 響應(yīng)。

事實上，在打樁和調(diào)樁之間還隱藏著一件不顯山露水、但是及其重要的事情，那就是 mock 樁的注入(mock injection)。

什么是 mock 注入?

mock 的本質(zhì)就是用模擬樁來替換真實的依賴。所謂 mock 樁注入就是阻斷被測服務(wù)與真實服務(wù)之間的鏈路，建立被測服務(wù)與 mock 之間的鏈路過程。

如何注入 mock?

總的來說 mock 樁的注入方式與架構(gòu)、被測服務(wù)的架構(gòu)等因素相關(guān)，在實際中常見的 mock 樁注入方式包括但不限于以下五種。

(1)API 請求構(gòu)造

在 mock 接口中被測服務(wù)是 API 的請求方，即客戶端;依賴服務(wù)是 API 的響應(yīng)方，即服務(wù)端。根據(jù) mock 工作的位置，mock 可以分為客戶端 mock 和服務(wù)端 mock。

客戶端 mock：mock 在被測服務(wù)內(nèi)部工作，直接攔截被測服務(wù)的 API 請求方法(比如 HTTP Client方法)，在被測服務(wù)調(diào)用 API 請求方法時，直接從方法內(nèi)部返回預(yù)定義的 mock 響應(yīng)。

服務(wù)端 mock：mock 在被測服務(wù)外部工作，作為 HTTP 服務(wù)器接收被測服務(wù)發(fā)送的 API 請求，并返回預(yù)定義的 mock 響應(yīng)。

客戶端 mock 的注入其實就是改造被測服務(wù)的 API 請求方法，即在 API 請求方法中加入 mock 處理邏輯。當滿足某些條件時執(zhí)行 mock 分支，不滿足時執(zhí)行真實分支。

可以通過兩種方式實現(xiàn)，一種是直接改造源代碼，另一種是利用字節(jié)碼增強技術(shù)對字節(jié)碼進行改造(Java 語言)。

API 請求改造這種注入方式適用于客戶端 mock，其優(yōu)勢性能極好，其不足是實現(xiàn)成本較高。

(2)本地配置

對于服務(wù)端 mock，打樁之后會生成唯一的 mock 樁地址。被測服務(wù)要想調(diào)用這個樁需要知道樁地址，如何讓被測服務(wù)知道樁地址呢?一種最直接的方法就是被測服務(wù)提供一個依賴服務(wù)地址配置項，在需要使用 mock 時將依賴服務(wù)地址修改成 mock 地址。

本地配置的優(yōu)勢是實現(xiàn)簡單，不足之處是修改配置項需要重啟被測服務(wù)，在需要進行 mock 服務(wù)與真實服務(wù)切換時不方便。

(3)配置中心

在服務(wù)端 mock 中，為了避免修改依賴服務(wù)地址配置項導致被測服務(wù)重啟，可以采用配置中心(如 Spring Cloud Config Server)存儲和管理依賴服務(wù)地址配置，或者使用注冊中心(如 Spring Cloud Eureka)記錄服務(wù)與服務(wù)地址的映射關(guān)系。

使用配置或者注冊中心時，mock 注入的方法是修改配置中心，將依賴服務(wù)地址改成 mock 地址。這種注入方法不需要重啟被測服務(wù)，但是從配置改變到配置生效可以存在一定的延時。

(4)反向代理

在微服務(wù)架構(gòu)下，被測服務(wù)與依賴服務(wù)之間可能不是直連的，而是經(jīng)過了一層反向代理，例如 API 網(wǎng)關(guān)。在這種情況下，被測服務(wù)是通過調(diào)用 API 網(wǎng)關(guān)來間接調(diào)用依賴服務(wù)的接口。

在 API 網(wǎng)關(guān)模式下，mock 注入的具體做法就是修改 API 網(wǎng)關(guān)配置，將依賴服務(wù) API 網(wǎng)關(guān)接口綁定的地址改成 mock 地址。

這種注入的優(yōu)勢是對被測服務(wù)無侵入，并且實現(xiàn)更細粒度(接口級)的 mock。當然，根據(jù) API 網(wǎng)關(guān)的實現(xiàn)不同，仍然可能存在一定的時延。亞馬遜 AWS 的 API 網(wǎng)關(guān)就是采用這種方式進行 mock。

(5)前向代理

服務(wù)端 mock 除了作為 HTTP 服務(wù)器，還可以兼?zhèn)?HTTP 代理的功能，這種架構(gòu)又叫做 mock 代理，例如 mock server proxy。對于 mock 代理來說，它不僅能夠返回 mock 響應(yīng)，而且能夠在需要的時候?qū)?API 請求轉(zhuǎn)發(fā)給依賴服務(wù)，并將依賴服務(wù)的真實響應(yīng)返回給被測服務(wù)。

使用前向代理模式，mock 注入的方式是將被測服務(wù)的依賴地址或網(wǎng)絡(luò)代理修改為 mock 地址，這種注入方法需要重啟被測服務(wù)，其優(yōu)勢是能夠?qū)崿F(xiàn)細粒度的 mock，并且能夠根據(jù)錄制的真實響應(yīng)自動生成 mock。

五種注入方式對比

一張表格總結(jié)一下

不可忽視的mock兩大功能

關(guān)于 mock，經(jīng)常容易被誤解的是：認為 mock 只是模擬返回的結(jié)果而已。

實際上 mock 還可以提供兩大功能：(1)記錄真實的調(diào)用信息;(2)生成模擬的返回信息;

對于測試用例來說，我們不僅關(guān)心 mock 是否返回了期望的結(jié)果，還需要關(guān)心 SUT 是否以期望的方式調(diào)用了 mock 對象。

如果 SUT 沒有以期望的方式調(diào)用，比如：沒有傳參或者參數(shù)不對，那么 SUT 就存在問題。

mock 需要詳細記錄來自SUT 的調(diào)用信息，并提供給用例來校驗。比如 Java mockito 就提供了此類校驗功能：

List<String> mockedList = mock(MyList.class); 
mockedList.size(); 
// 校驗 size 函數(shù)調(diào)用且只調(diào)用了1次 
verify(mockedList, times(1)).size(); 

常用 mock 工具

單元測試級別

這個級別的mock工具有easymock、jMock、Mockito、Unitils Mock、PowerMock、JMockit等，關(guān)于各自優(yōu)劣勢大家可以上網(wǎng)查詢。

接口測試級別

接口級別的mock工具完成的主要功能是對一個用戶的請求，模擬server返回一個接口的響應(yīng)數(shù)據(jù)。常用的有：

• Wiremock
• Mockserver
• Moco
• Mock.js
• RAP

mock 不是銀彈

說了這么多 mock 的好處，實際上 mock 也有很多不足，比如：

• (1)mock 可能導致問題遺漏。mock 的模擬行為與真實行為可能存在 GAP，導致基于 mock 的測試雖然通過了，但是基于真實對象的測試卻失敗了，這意味著問題被遺漏了。mock 很難模擬所有的真實情況。
• (2)mock 帶來較高的維護成本?；?mock 的測試用例結(jié)構(gòu)比較復雜，實現(xiàn)和維護都不容易，后期被測代碼有變動時需要適配 mock 代碼。

簡單一句話：mock 不是銀彈。

有態(tài)度的總結(jié)

mock 不是銀彈，mock 是有利有弊的，一張圖總結(jié)一下：

說了這么多，在工作中如何正確使用 mock 呢?這里提兩點建議，敲黑板啦。

(1)不要過度使用 mock。測試用例中掌握好使用 mock 的度。在涉及網(wǎng)絡(luò)訪問、數(shù)據(jù)庫讀寫、操作系統(tǒng)交互等系統(tǒng)級調(diào)用，優(yōu)先使用 mock。

(2)不要過度依賴基于 mock 的測試結(jié)果?；?mock 的測試無論多么充分，這都不能保證不出現(xiàn)問題的遺漏。一個完整的測試策略一定是由基于 mock 的測試和基于非 mock 的測試共同組成的，二者相輔相成缺一不可。