蘑菇街支付金融Android單元測試實踐(4)

　　對于這個流程，我們做了如下的單元測試：

　　CheckoutActivity啟動單元測試：通過Robolectric提供的方法，啟動一個Activity。驗證里面的mCheckoutModel的loadCheckoutData()方法得到了調用，同時參數(訂單ID等)是對的。

　　CheckoutModel的loadCheckoutData單元測試1：調用CheckoutModel的loadCheckoutData()方法，驗證里面的mApi對應的get方法得到了調用，同時參數是對的。

　　CheckoutModel的loadCheckoutData單元測試 2：mock Api類，指定當它的get方法在收到某些調用的時候，直接調用傳入的callback的onSuccess方法，然后調用CheckoutModel的 loadCheckoutData()方法，驗證Otto bus的post方法得到了調用，并且參數是對的。

　　CheckoutModel的loadCheckoutData單元測試 3：mock api類，指定當它的get方法在收到某些調用的時候，直接調用傳入的callback的onFailure方法，然后調用CheckoutModel的 loadCheckoutData()方法，驗證Otto bus的post方法得到了調用，并且參數是對的。

　　CheckoutActivity的onCheckoutDataLoaded單元測試1：啟動一個CheckoutActivity，調用他的onCheckoutDataLoaded()，傳入含有正確數據的Event，驗證相應的數據view顯示出來了

　　CheckoutActivity的onCheckoutDataLoaded單元測試2：啟動一個CheckoutActivity，調用他的onCheckoutDataLoaded()，傳入含有錯誤信息的Event，驗證相應的錯誤提示view顯示出來了。

　　這里需要說明的一點是，上面的每一個測試，都是獨立進行的，不是說下面的單元測試依賴于上面的?；蛘哒f必須先做上面的，再做下面的。

　　這部分較為詳細的代碼放在 github (https://github.com/ChrisZou/android-unit-testing-tutorial)上，groupshare這個package里面。

　　其他的問題

　　以上就是我們這邊做單元測試用到的技術，以及一個基本流程，下面聊聊其他的幾個問題。

　　哪些東西需要測試呢?

　　所有的Model、Presenter/ViewModel、Api、Utils等類的public方法

　　Data類除了getter、setter、toString、hashCode等一般自動生成的方法之外的邏輯部分

　　自定義View的功能：比如set data以后，text有沒有顯示出來等等，簡單的交互，比如click事件，負責的交互一般不測，比如touch、滑動事件等等。

　　Activity的主要功能：比如view是不是存在、顯示數據、錯誤信息、簡單的點擊事件等。比較復雜的用戶交互比如onTouch，以及view的樣式、位置等等可以不測。因為不好測。

　　CI和code coverage： Jacoco

　　要把單元測試正式化，CI是非常重要的一步，我們有一個運行Jenkins的CI server，每次開發者push代碼到master branch的時候，會運行一次單元測試的gradle task，同時使用 Jacoco 做code coverage。

　　這里有個坑要特別注意，那就是項目里面的gradle Jacoco插件和 Jenkins的Jacoco插件 的兼容性問題。我們用的gradle Jacoco插件是7.1，更高版本的好像有問題。然后對應的Jenkins的Jacoco插件需要1.0.19或更低版本的，更高版本的jenkins plugin不支持低版本的gradle Jacoco項目版本。實際上，這點在Jenkins的Jacoco插件首頁就有說明：

　　(點擊放大圖像)

　　但是我當時沒注意，所以覆蓋率數據一直出不來，折騰了好一會，最后還是在同事的幫助下找到問題了。

　　遇到的坑，以及好的practice建議

　　接下來講講我們遇到的一些坑，以及一些好的practice建議。

　　1. Native libary

　　無論是純JUnit還是Robolectric，都不支持load native library，會報UnsatisfiedLinkError的錯。所以如果你的被測代碼里面用到了native lib，那么可能需要給System.loadLibrary加上try catch。

　　如果是被測代碼用到的第三方lib，而里面用到了native lib的話，一般有兩種解決辦法，一種是將用到native lib的第三方類外面自己在包一層，然后在測試的情況下mock掉。第二種是用Robolectric，給那個類創建一個shadow class。

　　第一種方法的好處是可以在測試的時候隨時改變這個類的返回值或行為，缺點是需要另外創建一個wrapper類，會有點繁瑣。第二種方式不能隨時改變這個類的行為，但是寫起來非常簡單。所以，看自己的需要，選擇相應的方法。

　　這兩種方法，也是解決static method, final class/method不能mock的主要方式。

　　2. 盡量寫出易于測試的代碼

　　static method、直接new object、singleton、Global state等等這些都是一些不利于測試的代碼方式，應該盡量避免，用依賴注入來代替這些方式。

原文轉自： http://www.infoq.com/cn/articles/mogujie-android-unit-testing