Android單元測試

　　根據維基百科的解釋，單元測試又稱為模塊測試。是針對程序單元來進行正確性校驗的測試工作。程序單元是應用的最小可測試部件。在過程化編程中，一個單元就是單個程序，函數，過程等，對于面向對象編程，最小單元就是方法。

　　? 通常來說，程序員每修改一次程序就會進行最少一次單元測試，在編寫程序的過程中前后可能要進行多次單元測試，以證實程序滿足需求。

　　? 那為什么要做單元測試呢?

　　? 我們首先來看看Android 程序員常見的自測方式:

　　? 實現某個功能后，在手機上執行整個應用，然后在手機上操作應用，在界面上多次點擊后，進入使用該功能的場景，然后測試該功能，通常只會測試功能執行的主路徑。也就是說如果功能有多分支結構(if-else)，那么自測時只會測試一條主路徑，其它分支結構都會交給測試人員進行人工測試。

　　? 那這樣做有什么問題呢?

　　? 如果每次實現功能時都能確保沒問題，那上述流程看起來就沒啥大問題了。但事實上，我們每次實現某個功能時，誰都不敢保證寫完功能實現代碼一定能保證它一點問題沒有，誰能這么說，我也只能呵呵了。實際上，我們每次實現的功能或多或少都會存在問題，我們需要反復修改代碼，來測試我們的邏輯是否正常，按照上述的流程，我們修改完代碼后需要編譯生成apk, 連接手機，將應用安裝至手機，這幾步通常就需要2分鐘，然后再在手機上操作進入使用功能場景的地方，測試功能場景，并觀察結果，這一般需要1分鐘。所以我們每次寫完代碼后，需要3分鐘進行驗證，如果修改5次，每次定位問題并修改邏輯的時間為2分鐘，那么確保該功能主邏輯沒問題需要5*(2+3)=25分鐘，其中60%的時間(15分鐘)用于驗證問題，40%的時間(10分鐘)用于真正的解決問題。

　　? 從這個角度看，這種自測方式非常低效，還需要程序員不斷在電腦上的編程IDE和手機的應用之間切換，并且還要在手機上反復執行重復操作，對于程序員來說，其實是一件很痛苦的事情，也很容易誤操作。有時候等待手機連接到電腦還要等半天，尤其是裝驅動有時候要裝半天，甚至adb沖突導致連接也要等非長久，有時候公司要求歸還開發用的手機，換一部新的開發機，使用新的開發手機會非常不熟悉，在手機上打開調試模式都要半天，這些都是非常耽誤工作效率的事情，讓程序員非常痛苦。

　　? 另外，這種測試通常只會測試功能執行的主流程，還有很多分支流程不會執行，交給測試人員執行時，因為測試人員通常都是做黑盒測試，所以對內部邏輯不會太了解，很容易遺漏某些分支的測試，并且這些分支的準備條件對于測試人員來說也很不好準備，所以即使知道，也會忽略某些分支的測試。而這些分支如果有問題，到了用戶側就會暴露出來了。所以這種測試沒法保證功能的非主分支也能執行正常。

　　? 另外，這種測試方式即使讓功能的初次實現沒問題了，后續迭代過程中會不斷修改它的邏輯，或者它依賴的邏輯，這時候問題就出來了，因為我們修改它依賴的邏輯后，并不會再讓測試同學測試這個功能。我們可能都遇到過這種場景，我們將某個Bug修改好了之后，過一段時間后，我們修改另外一個Bug，這個Bug修改好了，結果前一陣子修改的Bug又出現了。這是為什么呢?因為我們修改Bug時通常都會專注這一個Bug，修改邏輯時，只會專注于將引起這個問題的邏輯調整正確，但是將引起這個問題的邏輯調整后之后，有可能導致其它問題。比如，如果函數A調用函數C，希望它返回"Hello", 函數B調用函數C，希望它返回"Hello2", 某一天函數A希望函數C返回"HelloC"了，于是修改了函數C的邏輯，結果函數A調用函數C確實返回了"HelloC"，然而函數B調用函數C也返回"HelloC"了，那么這就有問題了。而我們可能并不會注意到這個問題，就直接發了版本，到了用戶側，就有大量用戶抱怨了。如果我們每次發版本時，將所有曾出現過的Bug以及所有的功能都測試一遍，那么需要非常長的時間，會嚴重耽誤項目進度。

　　? 我們再回到當初的問題，為什么做需要做單元測試，從上述幾個角度已經看到通常的自測方式存在的問題，那我們看使用單元測試是如何解決這些問題的:

　　低效的問題

　　使用JUnit的單元測試時，可以脫離手機進行代碼邏輯正確性的驗證，也不需要在手機上操作，執行測試用例后直接輸出測試結果是否正常，如果正常就是綠顏色的執行結果，如果失敗就是紅顏色的執行結果，可以將驗證操作的時間縮短到30s內。當然我們需要花一定的時間在編寫測試用例上，不過這只是一個一次性的工作。

原文轉自： http://www.cloudchou.com/android/post-909.html