單元測試概述

一、爲何須要單元測試

    軟件開發的標準過程包括如下幾個階段：［需求分析階段］、［設計階段］、［實現階段］、［測試階段］、［發佈］。其中測試階段經過人工或者自動手段來運行或測試某個系統的過程，其目的在於檢驗它是否知足規定的需求或弄清預期結果與實際結果之間的差異。按照軟件工程思想，軟件測試能夠分爲單元測試、集成測試、功能測試、系統測試等。功能測試和系統測試通常來講是測試人員的職責，但單元測試和集成則必須由開發人員保證。

    1）單元測試：單元測試時開發者編寫的一小段代碼，用於檢驗目標代碼的一個很小的、很明確的功能是否正確。一般而言，一個單元測試用於判斷某個特定條件或特定場景下某個特定函數的行爲。在一個狀況下，一個功能模塊每每會調用其餘功能模塊完成某項功能，如業務層的業務類可能會調用多個DAO完成某項任務。對某個功能模塊進行單元測試時，咱們但願屏蔽對外功能模塊的依賴，以便將焦點放在目標功能模塊的測試上。這時模擬對象是最有力的工具，它依據外在模塊的接口模擬特定操做行爲，這樣單元測試就能夠在假設關聯模塊正確工做的狀況下驗證本模塊邏輯的正確性了。

    2）集成測試：集成測試是在功能模塊開發完成之後，爲驗證功能模塊之間匹配調用的正確性而進行的測試。在單元測試時，每每須要經過模擬對象屏蔽外在模塊的依賴，而集成測試偏偏是要驗證模塊之間集成後的正確性。

    3）功能測試：功能測試主要檢查已實現的軟件是否知足了需求規格說明中肯定了的各類需求，以及軟件功能是否徹底、正確。

    4）系統測試主要對已經通過肯定的軟件歸入實際運行環境中，與其餘系統成份組合在一塊兒進行測試。

 

二、測試的好處

    1）是軟件質量最簡單、最有效的保證；

    2）是目標代碼最清晰、最有效的文檔；

    3）能夠優化目標代碼的設計；

    4）是代碼重構的保障；

    5）是迴歸測試和持續集成的基石。

 

三、單元測試基本概念

    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）是測試框架裏面的若干個方法，用來判斷某個語句的結果是否爲真或判斷是否與預期相符。