前言

京東APP核心購物流程因其重要性，內(nèi)部稱之為黃金購物流程，公司各大業(yè)務(wù)事業(yè)部都有許多個性化訴求，每個版本承接的需求量很大。研發(fā)在保證需求完成數(shù)量的同時，還需要保證代碼質(zhì)量和持續(xù)提升開發(fā)效率，對于工具的應(yīng)用就顯得非常急迫。

iOS Mocker是我們部署的一套服務(wù)端接口Mock工具，主要用于業(yè)務(wù)開發(fā)過程解耦、測試數(shù)據(jù)保存和分享、客戶端容錯測試等場景。目前已完成搜索、商詳、購物車等核心購物流程的接入，內(nèi)部存儲的數(shù)據(jù)基本覆蓋了這些模塊所有線上可能出現(xiàn)的接口返回場景，為各模塊的版本迭代和代碼重構(gòu)提供了更全面的數(shù)據(jù)保障。

現(xiàn)狀和痛點

?

開發(fā)過程客戶端依賴服務(wù)端接口進行聯(lián)調(diào)

在開發(fā)階段，客戶端和服務(wù)端同時進行需求開發(fā)，客戶端在有些需求上可能需要等待服務(wù)端需求上線之后再進入開發(fā)，這種等待是不必要的，也增加了客戶端后期的工作壓力。

?

客戶端更便捷的積累和獲取驗證數(shù)據(jù)

以搜索結(jié)果頁的商品列表為例，由于商品種類繁多，特性差異巨大，列表頁中給每個商品的展示區(qū)域雖然很小，但是卻希望將每個商品的賣家、好評、促銷等特征信息全面的呈現(xiàn)出來，所以每個商品占位僅有242像素高的cell上總共分出了9個區(qū)域。每個區(qū)域的展示根據(jù)服務(wù)端下發(fā)配置的不同，不同機型適配邏輯不同，組合成200多種不同的展示形態(tài)。手機品類的幾種情況如下圖：

?

由于cell有復用機制，在線上環(huán)境，cell中的每一種布局在理論上都有被回收復用到另一種布局的可能。那么，我們?nèi)绾伪ＷC每一種布局之間相互復用都不會有問題？如何保證在某個區(qū)域新增加一種展示方案后，不會對相關(guān)區(qū)域造成不確定的影響？這種全面驗證的主要難點在于特殊數(shù)據(jù)的積累上，需要一個工具來輔助客戶端研發(fā)創(chuàng)建和積累這些特殊的驗證數(shù)據(jù)。數(shù)據(jù)積累之后，客戶端研發(fā)在代碼重構(gòu)和需求開發(fā)時能更方便更快速的進行驗證。

客戶端容錯和健壯性測試

在生產(chǎn)環(huán)境，客戶端做好接口容錯處理是必須的。比如接口某字段下發(fā)為null時候，進行各種容器操作會導致Crash，或者可能會導致界面顯示不能降級，所以容錯和健壯性測試也是很關(guān)鍵的。

Mocker目標

去除開發(fā)階段客戶端對服務(wù)端進度的依賴，研發(fā)在Mocker服務(wù)器上編輯Json數(shù)據(jù)，開發(fā)時對應(yīng)接口直接從Mocker服務(wù)器上拉取預先編譯好的數(shù)據(jù)進行解析，完成后續(xù)開發(fā)和自測，無需在客戶端添加額外的任何測試代碼。

Mock數(shù)據(jù)全面覆蓋客戶端所有測試用例需要的接口數(shù)據(jù)，回歸測試時或者代碼重構(gòu)之后，可以結(jié)合測試的代碼覆蓋率數(shù)據(jù)，保證完成了工程的全面驗證。

有效改善研發(fā)和測試的溝通和工作效率，研發(fā)在需求提測時候會攜帶驗證的Mock數(shù)據(jù)ID，測試在功能測試期間不需要依賴預發(fā)環(huán)境就可以進行測試；測試在發(fā)現(xiàn)問題向研發(fā)提出時候也會攜帶對應(yīng)的Mock數(shù)據(jù)ID，方便研發(fā)快速定位問題。