産品經理
前端開發進度如何？我的頁面依賴服務端接口，但小B同學開發的接口有各種問題，是以。。
前端小A
産品經理
抓狂ing。。。
産品經理
Hi，小B同學，你負責的接口開發進度如何了，什麼時候能提測？我的接口依賴于兄弟部門的xx接口，他們那邊開發進度太慢，導緻我沒法從他們那擷取資料，聯調不了，暫時無法提測。。
服務端小B
産品經理
吐血ing。。。
産品經理
Hi，小C同學，這個系統測試進度怎麼樣了，今天能上線嗎？逗我玩呢，這個系統依賴的第三方接口都沒準備好，有的根本沒有測試環境，今天測完，臣妾做不到啊！
測試小C
産品經理
#@￥%￥￥！@#
上面的情景是不是似曾相識呢？現今的業務系統已經很少是孤立存在的了，尤其對于一個大公司而言，各個部門之間的配合非常密切，我們或多或少都需要使用兄弟團隊或是其他公司提供的接口服務，當然，我們也會給其他兄弟部門提供接口。這樣的話，就對我們的聯調和測試造成了很大的麻煩。假如各個兄弟部門的步伐完全一緻，那麼問題就會少很多，但願望是美好的，現實是殘酷的，要做到步伐一緻基本是不可能的。是以，對于這種情況，我們的解決方案通常是搭建一個臨時的mock server來模拟那些兄弟部門未開發完成的接口，以達到單方面聯調測試的效果，我們下面會介紹一些mock小工具。一般來說，搭建這種臨時的mock server比較簡單，但是往往也意味着功能簡單，有時候可能我們得需要為不同的接口進行重複開發以實作特定功能。這樣的話問題就來了，随寫随仍不是我們網際網路人一貫的作風，我們需要将這種基礎服務傳承下去，要服務于衆多的其他網際網路人，我們稱之為share。那麼能不能建構一個通用的mock server呢？自己動手豐衣足食，萌生了自己開發一套mock系統，就有了現在的雛形——xMock，且聽我慢慢道來關于mock的二三事。
一、什麼是mock？
mock這個單詞解釋起來，本意就是模拟或者效仿。我們可以把mock了解為一個替身，在軟體開發領域，通常就是指模拟對象。
二、為什麼需要Mock？Mock是為了解決不同的單元之間由于耦合而難于開發、測試的問題。是以，Mock既能出現在單元測試中，也會出現在內建測試、系統測試過程中。
如上圖所示，A接口依賴于B、C、D三個接口，如果這三個接口沒有都準備好的話，我們必須對它們進行模拟才能繼續A接口的開發調試。
三、Mock的好處是什麼？ 1. 團隊可以并行工作
有了Mock，前後端人員隻需要定義好接口文檔就可以開始并行工作，互不影響，隻在最後的聯調階段往來密切；後端與後端之間如果有接口耦合，也同樣能被Mock解決；測試過程中如果遇到依賴接口沒有準備好，同樣可以借助Mock；不會出現一個團隊等待另一個團隊的情況。這樣的話，開發自測階段就可以及早開展，進而發現缺陷的時機也提前了，有利于整個産品品質以及進度的保證。
2. 開啟TDD模式，即測試驅動開發
單元測試是TDD實作的基石，而TDD經常會碰到協同子產品尚未開發完成的情況，但是有了mock，這些一切都不是問題。當接口定義好後，測試人員就可以建立一個Mock，把接口添加到自動化測試環境，提前建立測試。
3. 可以模拟那些無法通路的資源
比如說，你需要調用一個“牆”外的資源來友善自己調試，就可以自己Mock一個。
4. 隔離系統
假如我們需要調用一個post請求，為了獲得某個響應，來看目前系統是否能正确處理傳回的“響應”，但是這個post請求會造成資料庫中資料的污染，那麼就可以充分利用Mock，構造一個虛拟的post請求，我們給他指定傳回就好了。
5. 可以用來示範
假如我們需要建立一個示範程式，并且做了簡單的UI，那麼在完全沒有開發後端服務的情況下，也可以進行示範。說到示範了，假如你已經做好了一個系統，并且需要給客戶進行示範，但是裡面有些真實資料并不想讓使用者看到，那麼同樣，你可以用Mock接口把這些敏感資訊接口全部替換。
6. 測試覆寫度
假如有一個接口，有100個不同類型的傳回，我們需要測試它在不同傳回下，系統是否能夠正常響應，但是有些傳回在正常情況下基本不會發生，難道你要千方百計地給系統做各種手腳讓他傳回以便測試嗎？比如，我們需要測試在當接口發生500錯誤的時候，app是否崩潰，别告訴我你一定要給服務端代碼做些手腳讓他傳回500 。。。而使用mock，這一切就都好辦了，想要什麼傳回就模拟什麼傳回，媽媽再也不用擔心我的測試覆寫度了！
四、有哪些mock小工具既然Mock好處這麼多，還是趕緊看看有哪些Mock方法吧。下面我介紹下我接觸過的一些Mock小方法。 1. Mock Server-Moco這是一個jar包，隻要執行該jar包，指定配置檔案，就可開啟一個http伺服器提供服務，并且修改配置檔案後也無需重新開機服務，支援動态加載。我使用的是moco-runner-0.10.2-standalone.jar，運作方式如下：```java -jar moco-runner-0.10.2-standalone.jar start -p 8080 -c ***.json```***.json就是我們的mock配置檔案，比如：[ { "description": "api 1", "request" :{ "method" : "get", "uri" : "/foo" }, "response": { "json": {"foo":"bar"} } }]以上就可以實作當我們通路127.0.0.0:8080/foo時，傳回一個json為{"foo":"bar"}。
具體其他使用方法請參照官方文檔：https://github.com/dreamhead/moco/blob/master/moco-doc/apis.md
2. www.jsonohyeah.com
這是一個線上mock網站，操作簡單，但url是自動生成的，接口邏輯也無法實作定制化。考慮這樣一個場景：前端人員在使用mock接口時，肯定希望接口位址和最終上線的位址完全一樣，這樣就無需在聯調時修改接口位址了，隻需配置一個hosts，不然的話，改來改去難免改錯。對于這樣的場景，這個mock網站就實作不了，更不用說其他更加定制化的需求。
3. fiddlerfiddler大家都很熟了，可謂是居家旅行之必備，在windows環境可以随便自定義傳回内容，但一個很大的缺點是，它不跨平台，而我們平時的很多場景下，是需要在Linux下進行mock的。還有一些其他mock工具，大多都是通過編寫js代碼或者python、java等代碼來達到mock目的，此處就不再介紹了。
介紹了這麼多mock工具，那麼哪個最好使呢？我的要求其實不多，一是資料要好管理，别讓我管理一堆檔案；二是mock接口最好可以設定成和真實接口完全一緻，這樣就隻需要切換hosts就可以切換mock接口和真實接口，不需要修改代碼；三是跨平台，mock接口在windows和Linux下都需要可用。至于跨域、動态加載什麼的，這是必須條件。我的要求确實不多，但上面介紹的都沒法全部滿足。
五、xMock系統誕生始末xMock是BS架構，web頁面錄入接口資訊後，可以在任何平台下調用mock接口，滿足了跨平台；接口資訊儲存在資料庫中，解決了檔案方式不好管理的問題；web頁面錄入接口資訊，任何人都可以輕松操作，不需要代碼知識，使用門檻低；通過nginx通路配置好的mock接口，背景統一處理請求資訊，進行url比對，解決了mock接口和真實接口一緻性的問題。xMock系統使用非常簡單，隻要三步：填寫項目資訊，在對應項目下填寫接口資訊，配置hosts即可通路。頁面如下：
xMock系統的核心——mockserver，采用nginx作為前端代理，将接收到的所有請求全部轉發到背景mockserver，mockserver接收到請求後，對url進行預處理，根據url以及請求方式，在資料庫中查找對應的響應并傳回，流程如下圖：
好，xMock系統搭建起來了，正好有個需求，我們需要調用360移動開放平台的一個擷取特定賬号下app資訊的接口，但是這個接口在測試環境下無法得到想要的資訊，好了，我們按照真實接口的傳回格式，将我們想要的傳回以及其他資訊錄入xMock，然後在Linux配置hosts，将接口位址指向提供mock服務的ip，web産品頁面調用接口，歐耶，順利傳回了設定好的内容！
這就是mock帶給我們的便利。
xMock目前能解決哪些問題呢？-- 依賴的第三方系統接口還沒開發完畢，影響自己的開發進度；-- FE依賴RD提供的接口進行開發，而接口還沒有完成或頻繁重新開機；-- QA需要驗證接口某種特定傳回值或傳回狀态，而又不好通過功能模拟，比如支付；-- 性能測試，需要同步第三方系統或特定接口資料，需要重新搭建系統或申請權限、造大量資料；-- 與通過修改項目代碼寫死或者代碼mock這種mock方式而言，xMock做到了無需編寫任何代碼、對項目沒有任何副影響；-- Fiddler隻能在Windows平台，而xMock提供的mock服務是跨平台的。 xMock将來要解決哪些問題呢？其實，我們目前隻是有了mock最基本的功能，但對于接口而言，還會有很多可以模拟的地方，比如：-- 有時候會測試當接口逾時時，app端是否會正确提示，還是一直等待資源，也就是說，我們需要模拟逾時情況；-- 服務端和移動端進行通訊時，為了防止劫持，通常會将關鍵接口進行參數或者body加解密，也就是說，我們需要模拟加解密；-- 有時候會需要根據傳參的值來動态決定傳回的内容，也就是說，我們需要模拟接口邏輯；-- 有時候還得模拟https或者其他協定頭甚至自有協定；-- 能夠響應檔案、流媒體等；-- 能夠支援mock接口響應内容緩存到redis；-- 等等等等……