Android單元測試研究與實踐(26)

單元測試最終需要輸出文檔式的單元測試代碼，為線上代碼提供良好的代碼穩定性保證。

單元測試的流程

實際項目中，單元測試對象與頁面是一對一的，并不建議跨頁面，這樣的單元測試藕合度太大，維護困難。單元測試需要找到頁面的入口，分析項目頁面中的元素、業務邏輯，這里的邏輯不僅僅包括界面元素的展示以及控件組件的行為，還包括代碼的處理邏輯。然后可以創建單元測試case列表(列表用于紀錄項目中單元測試的范圍，便于單元測試的管理以及新人了解業務流程)，列表中記錄單元測試對象的頁面，對象中的case邏輯以及名稱等。工程師可以根據這個列表開始寫單元測試代碼。

單元測試是工程師代碼級別的質量保證工程，上述流程并不能完全覆蓋重要的業務邏輯以及邊界條件，因此，需要寫完后，看覆蓋率，找出單元測試中沒有覆蓋到的函數分支條件等，然后繼續補充單元測試case列表，并在單元測試工程代碼中補上case。

直到規劃的頁面中所有邏輯的重要分支、邊界條件都被覆蓋，該項目的單元測試結束。單元測試流程如圖5所示。

圖5 單元測試執行流程

上述分析頁面入口所得到結果便是@Before標記的函數中的代碼，之后的循環便是所有的case(@Test標記的函數)。

單元測試項目實踐

為了系統的介紹單元測試的實施過程，本文創建了一個小型的demo項目作為測試對象。demo的功能是供用戶發布所見的新聞到服務端，并瀏覽所有已經發表的新聞，是個典型的自媒體應用。該demo的開發和測試涉及到TextView、EditView、ListView、Button以及自定義View，包含了網絡請求、多線程、異步任務以及界面跳轉等。能夠為多數商業項目提供參照樣例。項目頁面如圖6所示。

圖6 單元測試case設計

首先需要分析App的每個頁面，針對頁面提取出簡短的業務邏輯，提取出的業務邏輯如圖6綠色圈圖所示。根據這些邏輯來設計單元測試的case(帶有@Test注解的那個函數)，這里的業務邏輯不僅指需求中的業務，還包括其他需要維護的代碼邏輯。業務流程不允許跨頁面，以免增加單元測試case的維護成本。針對demo中界面的單元測試case設計如下：

原文轉自：http://tech.meituan.com/Android_unit_test.html