上面的情景是否是似曾相識呢？現今的業務系統已經不多是孤立存在的了，尤爲對於一個大公司而言，各個部門之間的配合很是密切，咱們或多或少都須要使用兄弟團隊或是其餘公司提供的接口服務，固然，咱們也會給其餘兄弟部門提供接口。這樣的話，就對咱們的聯調和測試形成了很大的麻煩。假如各個兄弟部門的步伐徹底一致，那麼問題就會少不少，希望望是美好的，現實是殘酷的，要作到步伐一致基本是不可能的。因此，對於這種狀況，咱們的解決方案一般是搭建一個臨時的mock server來模擬那些兄弟部門未開發完成的接口，以達到單方面聯調測試的效果，咱們下面會介紹一些mock小工具。通常來講，搭建這種臨時的mock server比較簡單，可是每每也意味着功能簡單，有時候可能咱們得須要爲不一樣的接口進行重複開發以實現特定功能。這樣的話問題就來了，隨寫隨仍不是咱們互聯網人一向的做風，咱們須要將這種基礎服務傳承下去，要服務於衆多的其餘互聯網人，咱們稱之爲share。那麼能不能構建一個通用的mock server呢？本身動手豐衣足食，萌生了本身開發一套mock系統，就有了如今的雛形——xMock，且聽我慢慢道來關於mock的二三事。前端
1、什麼是mock？
mock這個單詞解釋起來，本意就是模擬或者效仿。咱們能夠把mock理解爲一個替身，在軟件開發領域，一般就是指模擬對象。java
2、爲何須要Mock？Mock是爲了解決不一樣的單元之間因爲耦合而難於開發、測試的問題。因此，Mock既能出如今單元測試中，也會出如今集成測試、系統測試過程當中。 python
如上圖所示，A接口依賴於B、C、D三個接口，若是這三個接口沒有都準備好的話，咱們必須對它們進行模擬才能繼續A接口的開發調試。nginx
3、Mock的好處是什麼？
1. 團隊能夠並行工做
有了Mock，先後端人員只須要定義好接口文檔就能夠開始並行工做，互不影響，只在最後的聯調階段往來密切；後端與後端之間若是有接口耦合，也一樣能被Mock解決；測試過程當中若是遇到依賴接口沒有準備好，一樣能夠藉助Mock；不會出現一個團隊等待另外一個團隊的狀況。這樣的話，開發自測階段就能夠及早開展，從而發現缺陷的時機也提早了，有利於整個產品質量以及進度的保證。git
2. 開啓TDD模式，即測試驅動開發
單元測試是TDD實現的基石，而TDD常常會碰到協同模塊還沒有開發完成的狀況，可是有了mock，這些一切都不是問題。當接口定義好後，測試人員就能夠建立一個Mock，把接口添加到自動化測試環境，提早建立測試。github
3. 能夠模擬那些沒法訪問的資源
好比說，你須要調用一個「牆」外的資源來方便本身調試，就能夠本身Mock一個。web
4. 隔離系統
假如咱們須要調用一個post請求，爲了得到某個響應，來看當前系統是否能正確處理返回的「響應」，可是這個post請求會形成數據庫中數據的污染，那麼就能夠充分利用Mock，構造一個虛擬的post請求，咱們給他指定返回就行了。數據庫
5. 能夠用來演示
假如咱們須要建立一個演示程序，而且作了簡單的UI，那麼在徹底沒有開發後端服務的狀況下，也能夠進行演示。說到演示了，假如你已經作好了一個系統，而且須要給客戶進行演示，可是裏面有些真實數據並不想讓用戶看到，那麼一樣，你能夠用Mock接口把這些敏感信息接口所有替換。json
6. 測試覆蓋度
假若有一個接口，有100個不一樣類型的返回，咱們須要測試它在不一樣返回下，系統是否可以正常響應，可是有些返回在正常狀況下基本不會發生，難道你要想方設法地給系統作各類手腳讓他返回以便測試嗎？好比，咱們須要測試在當接口發生500錯誤的時候，app是否崩潰，別告訴我你必定要給服務端代碼作些手腳讓他返回500 。。。而使用mock，這一切就都好辦了，想要什麼返回就模擬什麼返回，媽媽不再用擔憂個人測試覆蓋度了！windows
4、有哪些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配置文件，好比：
具體其餘使用方法請參照官方文檔：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下都須要可用。至於跨域、動態加載什麼的，這是必須條件。個人要求確實很少，但上面介紹的都無法所有知足。
5、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帶給咱們的便利。