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

表1 單元測試case列表

接下來需要在單元測試工程中實現上述case，最小斷言數是業務邏輯上的判斷，并不是代碼的邊界條件，真實的case需要考慮代碼的邊界條件，比如數組為空等條件，因此，最終的斷言數量會大于等于最小斷言數。在需求業務上，最小斷言數也是該需求的業務條件。

寫完case后需要跑一遍單元測試并檢查覆蓋率報告，當覆蓋率報告中缺少有些單元測試case列表中沒有但是實際邏輯中會有的邏輯時，需要更新單元測試case列表，添加遺漏的邏輯，并將對應的代碼補上。直到所有需要維護的邏輯都被覆蓋，該項目中的單元測試才算完成。單元測試并不是QA的黑盒測試，需要保證對代碼邏輯的覆蓋。

對表1分析，第一個頁面的“發布新聞”的case可以直接調用“編寫新聞”的case，以滿足條件“2.編寫了新聞的前提下，點擊發布按鈕”，在JUnit框架下，case(帶@Test注解的那個函數)也是個函數，直接調用這個函數就不是case，和case是無關的，兩者并不會相互影響，可以直接調用以減少重復代碼。第二個頁面不同于第一個，一進入就需要網絡請求，后續業務都需要依賴這個網絡請求，單元測試不應該對某一個條件過度耦合，因此，需要用mock解除耦合，直接mock出網絡請求得到的數據，單獨驗證頁面對數據的響應。

總結

單元測試并不是一個能直接產生回報的工程，它的運行以及覆蓋率也不能直接提升代碼質量，但其帶來的代碼控制力能夠大幅度降低大規模協同開發的風險?，F在的商業App開發都是大型團隊協作開發，不斷會有新人加入，無論新人是剛入行的應屆生還是工作多年，在代碼存在一定業務耦合度的時候，修改代碼就有一定風險，可能會影響之前比較隱蔽的業務邏輯，或者是丟失曾經的補丁，如果有高覆蓋率的單元測試工程，就能很快定位到新增代碼對現有項目的影響，與QA驗收不同，這種影響是代碼級的。

在本文所設計的單元測試流程中，單元測試的case和具體頁面的具體業務流程以及該業務的代碼邏輯緊密聯系，單元測試如同技術文檔一般，能夠體現出一個業務邏輯運行了多少函數，需要注意什么樣的條件。這是一種新人了解業務流程、對業務進行代碼級別融入的好辦法，看一下以前的單元測試case，就能知道與該case對應的那個頁面上的那個業務邏輯會執行多少函數，以及這些函數可能出現的結果。

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