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，這一切就都好辦了，想要什麼返回就模擬什麼返回。
    7.一些比較難構造的Object：這類Object一般有不少依賴，在單元測試中構造出這樣類一般花費的成本太大。

2. 根據需求選擇恰當的mock點

     對於Mock這裏存在兩個誤區，1.是Mock的對象越多越好；2.Mock會引入巨大的工做量，一般得不償失。這都是源於不恰當的Mock點的選取。

   這裏說的如何選擇恰當的mock點，是說對於一個被測對象，咱們應當在外圍選擇恰當的mock對象，以及須要mock的接口。由於對於任意一個對象，任意一段代碼邏輯咱們都是有辦法進行Mock的，而Mock點選擇直接決定了咱們Mock的工做量以及測試效果。從另一種意義上來講，不恰當Mock選擇反而會對咱們的測試產生誤導，從而在後期的集成和系統測試中引入更多的問題。

   在mock點的選擇過程當中，如下的一些點會是一些不錯的選擇

    

   • 網絡交互：若是兩個被測模塊之間是經過網絡進行交互的，那麼對於網絡交互進行Mock一般是比較合適的，如RPC
   • 外部資源：好比文件系統、數據源，若是被測對象對此類外部資源依賴性很是強，而其行爲的不可預測性極可能致使測試的隨機失敗，此類的外部資源也適合進行Mock。
   • UI：由於UI不少時候都是用戶行爲觸發事件，系統自己只是對這些觸發事件進行相應，對這類UI作Mock，每每可以實現很好的收益，不少基於關鍵字驅動的框架都是基於UI進行Mock的
   • 第三方API：當接口屬於使用者，經過Mock該接口來肯定測試使用者與接口的交互。
   • 固然如何作Mock必定是與被系統的特性精密關聯的，一些強制性的約束和規範是不合適的。這裏介紹幾個作的比較好的mock的例子。