【移動應(yīng)用開發(fā)技術(shù)】淺談Android單元測試的作用以及簡單示例

【移動應(yīng)用開發(fā)技術(shù)】淺談Android單元測試的作用以及簡單示例

前提概要受人嫌棄的單元測試對于單元測試這個知識點(diǎn)，其實(shí)很多開發(fā)者是不太接觸的，包括筆者，在實(shí)習(xí)之前也并未實(shí)用過單元測試，或者說并沒感受到單元測試的好處。

對于bug的調(diào)試，筆者之前更傾向于使用log和斷點(diǎn)調(diào)試，可以說會了這兩個，大部分的邏輯bug都能自己解決了。這兩個與看似臃腫的單元測試代碼相比更受大家的喜愛。

但是，使用log和斷點(diǎn)調(diào)試的前提是開發(fā)人員較少，甚至是單人開發(fā)的情況。如果我自己開發(fā)，我完全可以每次都使用集成測試，我知道每一個功能會涉及哪些模塊的代碼，然后根據(jù)邏輯設(shè)置log或者斷點(diǎn)調(diào)試。多人開發(fā)難以處理的問題然而，如果是多人開發(fā)呢？每一個模塊的代碼很可能是由不同的人分開負(fù)責(zé)的，bug的產(chǎn)生由不同模塊共同產(chǎn)生。每一個模塊的代碼可能都比較復(fù)雜，產(chǎn)生bug后，閱讀其他人的模塊本身比較浪費(fèi)時間，其次基本不可能讓你去修改其他人的代碼，這可能會破壞他人的代碼結(jié)構(gòu)。

而且錯誤可能也并不在其他人的代碼中，也可能是你們的交互方式有問題。產(chǎn)生bug的原因有太多，并且由單人直接log或者斷點(diǎn)調(diào)試難以處理，那么這種情況怎么辦呢？單元測試就一定程度上處理了這種困難的情況：給每一個模塊加上單元測試，如果該模塊可以通過單元測試，就代表沒有問題。

在這種情況下，程序員們面對的問題不再是要讓整個項(xiàng)目到達(dá)理想的效果，而是讓自己所面對的單元測試可以通過。這樣就大大減少了多人開發(fā)中的交互成本。簡單示例主要就兩個文件：

這個例子是測試了MainActivity.calculate()方法?？梢栽诓贿\(yùn)行這個app的情況下直接通過按SimpleTest.CalculateTest（）左邊的小三角測試，如下圖：

我們calculate()方法的邏輯是返回a+b+1，所以是4，最終不會報錯，如果我們把a(bǔ)ssertEquals中的4改成3，效果如下：

如圖，測試會直接報錯，并且定位到錯誤的那一行，然后我們就可以看到是MainActivity.calculate()輸出的值不等于3所造成的。Assert方法示例本身比較簡單，但是對于剛剛接觸單元測試讀者可能對assertEquals()比較陌生，這是Assert這個類中的靜態(tài)方法，單元測試中一般就是通過它來判斷是否達(dá)到理想的效果。

筆者此處使用了int之間的判斷，Assert中還有很多其他的用法，筆者可以去AndroidDevelpers上自己查看，此處為了方便，筆者為了方便就直接復(fù)制了。

總結(jié)這篇文章主要介紹了Android單元測試的作用和簡單的示例。但是簡單的對方法