一、什么是單元測試？

　　為了測試某個類中的某一個方法能否正常工作，而寫的測試代碼。

　　單元的定義：代碼中可度量的最小單元（函數(shù)/方法）；

　　是否正常工作：不同的輸入對應的輸出是否與預期一致。

二、單元測試有必要嗎？

　　1 對是否有必要寫單元測試的疑惑

　　沒有價值：不做單元測試一樣地開發(fā)，并沒有什么問題（解釋：）；

　　浪費時間：寫單元測試需要大量的時間，還不如寫具體的實現(xiàn)，具體的實現(xiàn)能看到明顯的效果，但單元測試可能耽誤正常的迭代進度；

　　無法測試：比如無返回值的方法、UI等；

　　2 不寫單元測試會存在的一些問題：

　　要有足夠的耐心：改一個參數(shù)，需要重新運行一遍程序；

　　沒有足夠的自信：每次提測和發(fā)布，心驚膽戰(zhàn)，對自己寫的程序沒有信心；

　　要有足夠的時間：必須要等到測試發(fā)現(xiàn)bug后才去改善；

　　bug太多，程序很難穩(wěn)定：可以看下你自己開發(fā)的應用，如果有做異常采集，上報的大多數(shù)異常問題，都是因為程序沒有做好容錯導致的，比如空指針、被除數(shù)為0、數(shù)組越界等；

　　3 單元測試能夠解決的問題

　　效率：如果沒有單元測試就必須把程序運行起來測試；運行一次單元測試，最多幾分鐘，cover得比較全面，相比于執(zhí)行程序，效率高很多很多；

　　質量：對于每個最小單元，針對不同輸入對應的輸出有與預期做對比，能夠減少因為參數(shù)導致的異常問題，同時提測和發(fā)布版本的時候，有信心；

　　提升設計能力：為了每個單元都可測，需要將每個方法拆得盡量獨立，如果不拆得足夠獨立，就無法測試，間接可以提高程序設計能力；

　　代碼重用：跑過單元測試的代碼，穩(wěn)定性能夠得到保證，可以在其它項目或者項目重構時重復利用；

　　縮短測試周期：程序自測（開發(fā)人員寫單元測試、手動跑基本功能、跑monkey都屬于自測）可以提高產品提測的質量，避免返工；同時核心功能的穩(wěn)定有助于縮短黑盒測試的周期。三、哪些可以做單元測試？

　　任何方法都可以做單元測試；

　　從必要性來講，針對UI相關的做單元測試必要性不大，并且很多東西需要主觀判斷；所以只針對Model和Control層做測試；

　　私有方法同樣可以測試（反射，或者在測試時改為public方法），但非public方法是這個類的實現(xiàn)細節(jié)，其它類并不關心，不用測試；

四、關于單元測試的一些概念

　　1 分類

　　按測試內容分：

　　功能測試：和UI無關，測試IO操作、算法、流程等；

　　UI測試：測試UI交互邏輯，比如點擊、登陸等；

　　按是否依賴設備分

　　不依賴Android設備，只需要運行在JVM上的；→真正的單元測試，執(zhí)行快，效率高；

　　依賴Android設備（模擬器/真機），需要程序運行時狀態(tài)信息的，比如獲取磁盤空間、四大組件的上下文信息、異步任務、消息傳遞等；→其實是集成測試，需要運行整個程序，執(zhí)行慢，效率低；

　　2 測試框架

　　如果沒有框架該如何做單元測試

　　自己寫程序進行邏輯判斷（麻煩、加入測試程序有bug怎么辦？）；

　　在console中觀察測試結果；

　　測試框架能夠提高測試效率

　　JUnit、Instrumentation test、Espresso、UI Automator、Robolectric、Appium、Robotium

　　JUnit：能夠直接在PC上執(zhí)行；

　　AndroidTest：需要依賴Android設備；

　　Robolectric：在不需要依賴Android環(huán)境的前提下，實現(xiàn)在PC上直接運行Android的單元測試；

　　Robotium：第三方UI測試框架；

　　Espresso：Google推出的UI測試框架；

　　UI Automator：流程的UI測試框架；

　　3 覆蓋率

　　衡量單元測試質量，通過覆蓋率測試，可以明確知道哪部分代碼已經被單元測試覆蓋到，哪部分沒有進行單元測試；常用的單元測試插件有Emma、JaCoCo；

　　4 JUnit框架中的常用方法

　　setUp/@Before：在每個單元測試方法執(zhí)行之前調用；

　　tearDown/@After：在每個單元測試方法執(zhí)行后調用；

　　setUpBeforeClass/@BeforeClass：在每個單元測試類運行前調用；

　　tearDownAfterClass/@AfterClass：在每個單元測試類運行完成后調用。

　　Junit3中每個測試方法必須以test打頭，Junit4中增加了注解，對方法名沒有要求，@Test就可以。

　　5 一個單元測試的流程

　　setUp：設置前提條件，比如初始化；

　　執(zhí)行動作：調用被測方法，并得到返回結果；

　　驗證結果：驗證獲取的結果和預期是否一致；

　　6 關于Mock

　　在寫單元測試的過程中，我們可能會發(fā)現(xiàn)需要和系統(tǒng)內的某個模塊或系統(tǒng)外某個實體交互，而這些模塊或實體在您做單元測試的時候可能并不存在，比如您遇到了數(shù)據(jù)庫、遇到了驅動程序等。這時開發(fā)人員就需要使用mock技術來完成單元測試。

　　mock就是創(chuàng)建一個類的虛假的對象，在測試環(huán)境中，用來替換掉真實的對象，以達到兩個目的：

　　驗證這個對象的某些方法的調用情況，調用了多少次，參數(shù)是什么等等；

　　指定這個對象的某些方法的行為，返回特定的值，或者是執(zhí)行特定的動作。

　　要使用mock技術，就需要使用mock框架，Mockito和Jmockit是android平臺兩個常用的mock框架，其中Mockito不能mock static method和final class、final method，但Jmockit可以。

　　7 依賴注入在單元測試中的使用

　 　上文中提到的Mock技術就是創(chuàng)建一個類的虛假的對象，在測試環(huán)境中用來替換掉真實的對象，但如何在測試環(huán)境下，將某個類替換成mock的對象就需要使 用到依賴注入了，他的基本理念是，某一個類（比如說DataActivity），用到的內部對象（比如說DataModel）的創(chuàng)建過程不在 DataActivity內部去new，而是由外部去創(chuàng)建好DataModel的實例，然后通過某種方式set給DataActivity。這種模式應用 是非常廣泛的，尤其是在測試的時候。常見的依賴注入框架有：Roboguice、Dagger、Dagger2。

　　在實際寫單元測試的過程中，mock技術會經常用到，所有非常有必要熟悉其中一種依賴注入框架，關于依賴注入的詳細解釋可以參見公共技術點之依賴注入。

五、單元測試集成到Jenkins

　　Jenkins上不需要任何改動，執(zhí)行現(xiàn)有的gradle命令會自動執(zhí)行單元測試，測試不通過會報編譯錯誤；

六、說明

　　不要指望對某個方法的單元測試一次能夠寫得足夠完美，單元測試也是需要持續(xù)迭代的（比如入參考慮得不全面、單元測試粒度沒有足夠細等）；

　　并不是所有針對源碼級別寫的測試代碼都叫單元測試，針對具體某一個方法的測試叫單元測試，涉及到UI層面、必須要運行程序才能跑的測試叫集成測試，比如很多基于android平臺的第三方UI測試框架；

　　test和androidTest文件夾的區(qū)別：如果你是用Android Studio做開發(fā)，在創(chuàng)建工程的時候，src文件夾下會同時生成三個文件夾main、test、androidTest，其中test和androidTest是專門針對源碼級別的白盒測試的，test 文件夾用于寫不依賴設備環(huán)境的單元測試，即直接在PC上即可運行的測試，特點是測試效率高；androidTest文件夾用于寫需要在設備上才能運行的測 試，比如測試依賴android API和設備環(huán)境的時候(context、IO操作、UI測試等)，就需要在這個文件夾下面寫單元測試了，其特點是必須要編譯生成APK后才能測試，效率 低；

　　測試驅動開發(fā)（TDD）的這種軟件開發(fā)方法提倡先寫測試程序，再才編碼實現(xiàn)具體的功能；

本文轉自（）

>>>關于測試分析的這些產品你可能感興趣

>>點擊查看更多軟件測試相關資訊<<