1、為什么需要單元測試
軟件開發的標准過程包括以下幾個階段：［需求分析階段］、［設計階段］、［實現階段］、［測試階段］、［發布］。其中測試階段通過人工或者自動手段來運行或測試某個系統的過程，其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。按照軟件工程思想，軟件測試可以分為單元測試、集成測試、功能測試、系統測試等。功能測試和系統測試一般來說是測試人員的職責，但單元測試和集成則必須由開發人員保證。
1）單元測試：單元測試時開發者編寫的一小段代碼，用於檢驗目標代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試用於判斷某個特定條件或特定場景下某個特定函數的行為。在一個情況下，一個功能模塊往往會調用其他功能模塊完成某項功能，如業務層的業務類可能會調用多個DAO完成某項任務。對某個功能模塊進行單元測試時，我們希望屏蔽對外功能模塊的依賴，以便將焦點放在目標功能模塊的測試上。這時模擬對象是最有力的工具，它依據外在模塊的接口模擬特定操作行為，這樣單元測試就可以在假設關聯模塊正確工作的情況下驗證本模塊邏輯的正確性了。
2）集成測試：集成測試是在功能模塊開發完成以后，為驗證功能模塊之間匹配調用的正確性而進行的測試。在單元測試時，往往需要通過模擬對象屏蔽外在模塊的依賴，而集成測試恰恰是要驗證模塊之間集成后的正確性。
3）功能測試：功能測試主要檢查已實現的軟件是否滿足了需求規格說明中確定了的各種需求，以及軟件功能是否完全、正確。
4）系統測試主要對已經經過確定的軟件納入實際運行環境中，與其他系統成份組合在一起進行測試。
2、測試的好處
1）是軟件質量最簡單、最有效的保證；
2）是目標代碼最清晰、最有效的文檔；
3）可以優化目標代碼的設計；
4）是代碼重構的保障；
5）是回歸測試和持續集成的基石。
3、單元測試基本概念
1）被測系統：SUT（System Under Test）
被測系統表示正在被測試的系統，目的是測試系統能否正確操作。軟件系統測試的一個特例是對應用軟件的測試，稱為被測應用程序（AUT，Application Under Test）。SUT也表明軟件已經到了成熟期，因為系統測試在測試周期中是集成測試的后一階段。
2）測試替身：Test Double
在單元測試時，使用Test Double減少對被測對象的依賴，使得測試更加單一。同時，讓測試案例執行的時間更短，運行更加穩定，同時能對SUT內部的輸入輸出進行驗證，讓測試更加徹底深入。但是，Test Double也不是萬能的，Test Double不能被過度使用，因為實際交付的產品是使用實際對象的，過度使用Test Double會讓測試變得越來越脫離實際。
要理解測試替身，需要了解一下Dummy Object， Test Stub，Test Spy， Fake Object這幾個概念。
a、Dummy Object：Dummy Object泛指在測試中必須傳入的對象，而傳入的這些對象實際上並不會產生任何作用，僅僅是為了能夠調用被測對象兒必須傳入的一個東西。
b、Test Stub：測試樁是用來接受SUT內部的間接輸入（indirect inputs），並返回特定的值給SUT。可以理解Test Stub是在SUT內部打的一個樁，可以按照我們的要求返回特定的內容給SUT，Test Stub的交互完全在SUT內部，因此，它不會返回內容給測試案例，也不會對SUT內部的輸入進行驗證。
c、Test Spy：Test Spy像一個間諜，安插在了SUT內部，專門負責將SUT內部的間接輸出（indirect outputs）傳到外部。它的特點是將內部的間接輸出返回給測試用例，由測試案例進行驗證，Test Spy只負責獲取內部情報，並把情報發出去，不負責驗證情報的正確性。
d、Mock Object：Mock Object和Test Spy有類似的地方，它也是安插在SUT內部，獲取到SUT內部的間接輸出（indirect outputs），不同的是，Mock Object還負責對情報（intelligence）進行驗證，總部（外部的測試案例）信任Mock Object的驗證結果。
e、Fake Object：經常，我們會把Fake Object和Test Stub搞混，因為它們都和外部沒有交互，對內部的輸入輸出也不進行驗證。不同的是，Fake Object並不關注SUT內部的間接輸入（indirect inputs）或間接輸出（indirect outputs），它僅僅是用來替代一個實際的對象，並且擁有幾乎和實際對象一樣的功能，保證SUT能夠正常工作。實際對象過分依賴外部環境，Fake Object可以減少這樣的依賴。
3）測試夾具：Test Fixture
測試夾具（Fixture），就是測試運行程序（test runner）會在測試方法之前自動初始化、回收資源的工作。在Junit4中通過@Before來初始化字段和配置環境，通過@After來進行注銷。這可以保證各個測試之間的獨立性和互不干擾，但是效率低。
一個測試用例可以包含若干個打上@Test注解的測試方法，測試用例測試一個或多個類API接口的正確性，當然在調用類API時，需要事先創建這個類的對象及一些關聯的對象，這組對象就稱為測試夾具（Fixture），相當於測試用例的“工作對象”。
4）測試用例：Test Case
在JUnit3中，測試方法都必須以test為前綴，且必須時public void的，JUnit4以后，就沒有這個限制，只要在每個測試方法標注@Test注解，方法簽名可以是任何取名。可以在一個測試用例類中添加多個測試方法，運行器為每個方法生成一個測試用例實例並分別運行。
5）測試套件：Test Suite
通過TestSuite對象將多個測試用例組裝成一個測試套件，則測試套件批量運行。需要特別指出的是，可以把一個測試套件整個添加到兩一個測試套件中，就像小籮筐裝進大籮筐變成一個筐一樣。
套件機制用於將測試從邏輯上分組並將這些測試作為一個單元測試來運行。Junit4為了替代老版本的套件測試，套件被兩個新注解替代：@RunWith、@SuteClasses。通過@RunWith指定一個特殊的運行器，即Suite.class套件運行器，並通過@SuiteClasses注解，將需要進行測試的類列表作為參數傳入。
創建步驟說明：
* 創建一個空類作為測試套件的入口（這個空類必須使用public修飾符，而且存在無參構造函數）；
* 將@RunWith、@SuiteClasses注釋修飾這個空類；
* 把Suite.class作為參數傳入@RunWith注釋，以提示Junit將此類指定為運行器；
* 將需要測試的類組成數組作為@SuiteClasses的參數。
6）斷言：Assertions
斷言（assertions）是測試框架里面的若干個方法，用來判斷某個語句的結果是否為真或判斷是否與預期相符。