說起軟件測試四個字，想必大家腦海中浮現(xiàn)的有集成測試、系統(tǒng)測試、黑盒測試、白盒測試等，可能就是沒想到會有單元測試。 對于大學(xué)是學(xué)習(xí)軟件工程專業(yè)出身的同學(xué)來說可能會聽過這四個字，對工作好幾年的職場老鳥可能也聽過但是沒實(shí)際用過居多。絕大多數(shù)的開發(fā)人員都是忙于把手頭的工作開發(fā)好，并不會把單元測試納入工作范疇，他們會說，我連功能開發(fā)都忙不過來了，哪有時(shí)間去做單元測試，況且還要寫測試代碼，那不是重復(fù)寫一篇代碼功能嗎？但，單元測試真的不值得花時(shí)間去做嗎，那是因?yàn)榭赡苣悴⒉磺宄卧獪y試的投入產(chǎn)出比有多高，下面就簡單介紹單元測試到底能給開發(fā)人員帶來多少好處。

·什么是單元測試
·為什么要做單元測試
·不寫單元測試借口
·主流框架 JUnit 和 TestNG
·Android 中的單元測試
·小結(jié)

什么是單元測試
單元測試本質(zhì)上也是代碼，與普通代碼的區(qū)別在于它是驗(yàn)證代碼正確性的代碼。可簡單做個定義：單元測試是開發(fā)人員編寫的、用于檢測在特定條件下目標(biāo)代碼正確性的代碼。
軟件開發(fā)天生就具有復(fù)雜性，沒人敢打包票說自己寫的代碼一點(diǎn)問題都沒有，或者不經(jīng)測試就能保證代碼正確運(yùn)行，可能你在這個執(zhí)行路徑下能夠執(zhí)行，殊不知還有其他路徑，有一一去驗(yàn)證過嗎，因此，要保證程序的正確性就必須要對我們代碼進(jìn)行嚴(yán)格測試。
舉個簡單例子：比如有個計(jì)算類，里面有個 add 方法，操作就是兩個數(shù)進(jìn)行相加。

public class Calculator {
    public int add(int one, int another) {
        //只是簡單的兩個數(shù)相加
        return one + another;
    }
}

常規(guī)做法：假如你寫好了這個方法，你想進(jìn)行驗(yàn)證 add 方法的正確性，需要寫個使用 add 方法的 main 函數(shù)，首先實(shí)例化 Calculator 類，然后調(diào)用 add 方法并傳入兩個參數(shù)，比如 1 和 2。然后你運(yùn)行這個工程，看得出結(jié)果是否為 3 ，如果是 3 ，則表明我這個方法寫的沒有錯誤，可能就不測試了，就繼續(xù)開發(fā)后續(xù)的功能，如果不是 3 ，則返回去看看代碼中哪里出錯了，重新進(jìn)行調(diào)試，甚至有時(shí)候肉眼還看不出代碼哪里出錯，此時(shí)就引入斷點(diǎn)去查看，在此期間，很大一部分時(shí)間就花在斷點(diǎn)、調(diào)試、運(yùn)行上。
單元測試做法：首先會利用 JUnit 測試框架（至于這個框架后面介紹）寫一段測試代碼，如下：

public class CalculatorTest {
    public void testAdd() throws Exception {
        Calculator calculator = new Calculator();
        int sum = calculator.add(1, 2);
        Assert.assertEquals(3, sum);
    }
}

這里的 CalculatorTest 是 Calculator 對應(yīng)的測試類，這里的 testAdd 對應(yīng)著 add 的測試方法，進(jìn)行測試一般分為三步驟：

setup。一般是 new 出你要測試的那個類，比如： Calculator calculator = new Calculator();
執(zhí)行操作。一般是調(diào)用你要測試的那個方法，獲得運(yùn)行結(jié)果： int sum = calculator.add(1, 2);
驗(yàn)證結(jié)果。驗(yàn)證得到的結(jié)果跟預(yù)期中是一樣的： Assert.assertEquals(3, sum);
看到 Assert 這個關(guān)鍵詞了嗎，這里可以理解為斷言或者期望值，根據(jù)入?yún)⒌闹?，期望有個什么值輸出，而不是靠肉眼去驗(yàn)證是不是自己想要的值，是直接通過判斷值是否相等性來驗(yàn)證會具有更客觀性。

以上介紹的只是單元測試一點(diǎn)點(diǎn)，那它能給我們帶來哪些更多好處呢？

為什么要做單元測試
通常我們在做任何工作會先考慮它的回報(bào)，編寫代碼更是如此。如果單元測試的作用不大，沒有人會愿意再寫一堆無用的代碼，那么單元測試到底能夠給我們帶來什么優(yōu)點(diǎn)呢？如下：

便于后期重構(gòu)。單元測試可以為代碼的重構(gòu)提供保障，只要重構(gòu)代碼之后單元測試全部運(yùn)行通過，那么在很大程度上表示這次重構(gòu)沒有引入新的BUG，當(dāng)然這是建立在完整、有效的單元測試覆蓋率的基礎(chǔ)上。

優(yōu)化設(shè)計(jì)。編寫單元測試將使用戶從調(diào)用者的角度觀察、思考，特別是使用TDD驅(qū)動開發(fā)的開發(fā)方式，會讓使用者把程序設(shè)計(jì)成易于調(diào)用和可測試，并且解除軟件中的耦合。

文檔記錄。單元測試就是一種無價(jià)的文檔，它是展示函數(shù)或類如何使用的最佳文檔，這份文檔是可編譯、可運(yùn)行的、并且它保持最新，永遠(yuǎn)與代碼同步。

具有回歸性。自動化的單元測試避免了代碼出現(xiàn)回歸，編寫完成之后，可以隨時(shí)隨地地快速運(yùn)行測試，而不是將代碼部署到設(shè)備之后，然后再手動地覆蓋各種執(zhí)行路徑，這樣的行為效率低下，浪費(fèi)時(shí)間。

等等，講了這么多優(yōu)點(diǎn)，無非就是良好的接口設(shè)計(jì)、正確性、可回歸、可測試、完善的調(diào)用文檔、高內(nèi)聚、低耦合，這些優(yōu)點(diǎn)已經(jīng)足以讓我們對單元測試重視起來了，但是個人覺得還有更重要的原因：
首先，帶來自信。在接手一個新的項(xiàng)目，或者說是參與一個新的項(xiàng)目開發(fā)時(shí)，往往這種情況是你半途參加進(jìn)去的，你需要對已有的代碼結(jié)構(gòu)進(jìn)行解讀和理解，對于業(yè)務(wù)的理解，對于代碼個中各個模塊關(guān)系的理解。如果一開始就理財(cái)出錯，很可能修改后的代碼會引起更多的BUG出現(xiàn)，到那時(shí)候又需要修復(fù)更多的BUG，改了一個地方，很有可能會莫名其妙地影響另外一個地方，這種現(xiàn)象是很常見的。還有一種情況，假設(shè)你修改的功能沒問題，但是需要去測試驗(yàn)證，在測試的時(shí)候就需要考慮這個功能點(diǎn)它原有的測試路徑有哪些，又需要一一去驗(yàn)證功能路徑，以證明本次修改對于已存在的功能點(diǎn)不造成影響。這其中就存在著很大的時(shí)間成本，導(dǎo)致效率不高。那是否存在著這么一種方式，我需要修改我想改動的地方，不需要關(guān)心修改完之后它所造成的影響，也不需要關(guān)心它的測試回歸性，有，此時(shí)就是單元測試登場的時(shí)候。寫單元測試代碼，可以讓我自己寫的代碼足夠自信，它是經(jīng)得起考驗(yàn)的。

其次，更快反饋。對于有一定編程經(jīng)驗(yàn)的開發(fā)人員來說，當(dāng)他拿到一個新需求的時(shí)候，首先想到的不是動手 Coding ，而是會先想想代碼的結(jié)構(gòu)，有些類，數(shù)據(jù)結(jié)構(gòu)該是如何，然后才開始敲代碼。如果沒有單元測試，一般流程基本是這個模塊功能全部寫完才開始測試，比如利用 MVP 架構(gòu)的功能。一般都是開始 Model 模塊,然后完善 Presenter 模塊，最后寫 View 模塊，等這幾個模塊都寫完了，再把 APP 跑起來，驗(yàn)證自己寫的功能模塊是否符合需求，沒有符合則繼續(xù)回去修改代碼，這中間需要花費(fèi)很長的時(shí)間才能知道當(dāng)下自己寫的代碼是否符合要求，是否正確。那有沒有一種即時(shí)反饋的方式呢，有，寫單元測試即可，當(dāng)你寫完一個函數(shù)，馬上就匹配一個單元測試函數(shù)，這樣即寫即測的方式可以保證你當(dāng)場寫的代碼馬上進(jìn)行修改，測試通過一個，就表示完成一個小的功能點(diǎn)，最后，把函數(shù)組裝起來，就是我們想要大的功能點(diǎn)。

最后，節(jié)約時(shí)間。對于 Android 開發(fā)來說，一遍一遍的運(yùn)行 APP ，然后執(zhí)行相應(yīng)的用戶操作，看界面是否正確的顯示，通過這種方式來測試功能，其實(shí)是非常浪費(fèi)時(shí)間，而且效率不高，而用單元測試，可以幾乎不用打開 APP 來執(zhí)行，當(dāng)然有些需要一些資源文件的是需要 APP 運(yùn)行條件，絕大部分的功能在單元測試階段就能驗(yàn)證完畢，那么速度就相對快很多。此外，單元測試還能幫忙減少 BUG ，從而減少調(diào)試 BUG 的時(shí)間，一些低級犯的錯誤在單元測試階段就能避免掉。

不寫單元測試借口
很多開發(fā)人員不寫單元測試，最重要的一個原因是他們并不知道單元測試能夠帶來什么好處，甚至根本不了解單元測試這個詞，那自然就像平行線般與之毫無交集。還有一個比較重要的原因是一些開發(fā)人員的編程思想還處在一個相對初級的階段，開發(fā)軟件只管實(shí)現(xiàn)功能，什么高內(nèi)聚、低耦合、重構(gòu)、設(shè)計(jì)、可測試等認(rèn)為太過專業(yè)，對于這些名詞以及意義還不了解，這自然不會考慮使用了。還有一些非思想層面的理由，如下：

單元測試太花時(shí)間了。軟件開發(fā)工作那么忙，代碼都寫不完哪有時(shí)間寫單元測試。這可能是開發(fā)人員用的最多的借口，從某些方面來說，這不能算借口，因?yàn)楹芏嚅_發(fā)人員確實(shí)在工作上投入的時(shí)間特別多。但真的是這樣的嗎，你有沒有想過，導(dǎo)致加班的原因也許就是花了太多時(shí)間在手動測試、調(diào)試程序上：或許你沒有考慮到靈活性與設(shè)計(jì)，使得在需求發(fā)生變更時(shí)你需要花很多時(shí)間在復(fù)雜的代碼堆中完成特定的功能，而這些修改又可能引入新的 BUG ，又將導(dǎo)致你需要進(jìn)行耗時(shí)的手動測試、調(diào)試等等，如此反復(fù)，代碼將變得越來越亂，越來越難以維護(hù)，最終導(dǎo)致無休止的加班。

測試不是我的工作。測試確實(shí)不是開發(fā)人員的工作，但單元測試確實(shí)是開發(fā)人員的工作，測試包含很多種，而只有單元測試是開發(fā)人員的工作范疇。開發(fā)人員為應(yīng)用編寫代碼，那么自然需要保證代碼的正確性，而單元測試正是這種保證代碼正確性的白盒測試，也就是在了解代碼內(nèi)部結(jié)構(gòu)邏輯的情況下進(jìn)行有目的的測試，既然說到了解代碼，那么開發(fā)者自然是最權(quán)威的人。因此，編寫單元測試并且為測試人員提交正確的代碼進(jìn)行其他測試是開發(fā)人員的職責(zé)所在。

代碼都編譯通過了，還測什么。一般來說，這是一個不會放在嘴上但可能藏在心里的借口。代碼編譯通過只能說你寫的代碼符合語法要求，并不代表能保證正確性。

代碼原來就沒有單元測試，并且難以測試。這個問題基本是接受和維護(hù)別人開發(fā)的代碼，而原來的代碼本身就沒有單元測試了，再加入如果代碼的耦合性較高，那么就更難以為這些代碼寫單元測試。此時(shí)正是你了解代碼時(shí)候，首先為能夠測試的部分添加單元測試，保證這些可測試的部分不會被污染，然后在對代碼有足夠的了解之后再對代碼進(jìn)行重構(gòu)，降低代碼的耦合性，并且慢慢補(bǔ)充測試用例，使得代碼的耦合性、可測試性慢慢建立起來。

主流框架 JUnit 和 TestNG
JUnit 是一個 Java 語言的單元測試框架，它是 xUnit 單元測試架構(gòu)體系的一個實(shí)例，用于編寫和運(yùn)行可重復(fù)的測試。它包括以下特性：
用于測試期望結(jié)果的斷言（Assertion）
用于共享共同測試數(shù)據(jù)的測試工具
用于方便的組織和運(yùn)行測試的測試套件
圖形和文本的測試運(yùn)行器

TestNG 是一個測試框架，其靈感來自 JUnit 和 NUnit ，但引入了一些新的功能，使其功能更強(qiáng)大，使用更方便。TestNG 消除了大部分的舊框架的限制，使開發(fā)人員能夠編寫更加靈活和強(qiáng)大的測試。 因?yàn)樗诤艽蟪潭壬辖梃b了Java注解( JDK5.0 引入的)來定義測試，它也可以顯示如何使用這個新功能在真實(shí)的Java語言生產(chǎn)環(huán)境中。

特點(diǎn)如下：
注解
TestNG 使用 Java 和面向?qū)ο蟮墓δ?br> 支持綜合類測試(例如，默認(rèn)情況下，不用創(chuàng)建一個新的測試每個測試方法的類的實(shí)例)
獨(dú)立的編譯時(shí)測試代碼和運(yùn)行時(shí)配置/數(shù)據(jù)信息
靈活的運(yùn)行時(shí)配置
主要介紹“測試組”。當(dāng)編譯測試，只要要求 TestNG 運(yùn)行所有的“前端”的測試，或“快”，“慢”，“數(shù)據(jù)庫”等
支持依賴測試方法，并行測試，負(fù)載測試，局部故障
靈活的插件 API
支持多線程測試

Android 中的單元測試
因?yàn)?JUnit 測試框架是基于 Java 語言，當(dāng)然 Android 開發(fā)也是基于 Java 語言，所以在 Android 中我們可以用 Junit4 單元測試框架進(jìn)行回歸測試，但同時(shí)，Google 也提供了一個 AndroidJUnit4 測試框架，看名字就知道它是基于 JUnit 4 框架適合在 Android 環(huán)境中做單元測試。

那么，AndroidJUnit4 和 Junit4 有什么區(qū)別呢？很大一個區(qū)別在于：
1，AndroidJUnit4 測試可以在真機(jī)的環(huán)境下進(jìn)行。比如你要測文件讀取SD卡，或者操作 SqlLite 數(shù)據(jù)庫，這些條件只有在真機(jī)上才有的，此時(shí)你用 AndroidJUnit4 框架測試，可以直接跑起來用真實(shí)的環(huán)境做相應(yīng)的單元測試。
2，JUnit4 測試是運(yùn)行在工程項(xiàng)目中，也就是在編譯階段。此時(shí)如果想要模擬 Android 環(huán)境，比如我想用 JUnit4 來測試 Activity 類，那么就需要引用第三方庫來支持，引用 Mockito 和 Robolectric 框架來模擬 Android 環(huán)境進(jìn)行相應(yīng)的單元測試。
所以何時(shí)用 AndroidJUnit4 和 JUnit4 不同的框架進(jìn)行單元測試，就看你待測試的方法前置條件是什么，然后做不同的選擇。

小結(jié)
總的來說，單元測試不是集成測試，單元測試只是測試一個方法單元，不是測試一整個流程。集成測試是一種End To End的系統(tǒng)測試，測試相關(guān)模塊集成在一起是否能夠按照預(yù)期工作，一般都是接口或者功能層面的測試，可能會依賴很多系統(tǒng)因素，測試的代碼邏輯一般比較復(fù)雜，運(yùn)行時(shí)間會比較長，出錯之后的修復(fù)成本高。單元測試則是開發(fā)者在集成測試之前就已經(jīng)進(jìn)行自測過，同時(shí)呢，進(jìn)行單元測試之后，對于某個方法的執(zhí)行路徑組合進(jìn)行了一一驗(yàn)證，它只關(guān)注三個目標(biāo)：

1、有明確的返回值。比如對某個函數(shù)進(jìn)行單元測試，驗(yàn)證其返回值是否符合預(yù)期結(jié)果。
2、這個函數(shù)只改變其對象內(nèi)部的一些屬性或者狀態(tài)，函數(shù)本身沒有返回值，就驗(yàn)證它所改變的屬性和狀態(tài)。
3、一些函數(shù)沒有返回值，也沒有直接改變哪個值的狀態(tài)，這就需要驗(yàn)證其行為，比如點(diǎn)擊事件。