為什麼需要單元測試

軟體開發的標準過程包括以下幾個階段：『需求分析階段』→『設計階段』→『實現階段』→『測試階段』→『發布』。其中測試階段通過人工或者自動手段來執行或測試某個系統的過程，其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。測試過程按4個步驟進行，即單元測試、整合測試、系統測試及發版測試。其中功能測試主要檢查已實現的軟體是否滿足了需求規格說明中確定了的各種需求，以及軟體功能是否完全、正確。系統測試主要對已經過確認的軟體納入實際執行環境中，與其他系統成份組合在一起進行測試。單元測試、整合測試由開發人員進行，是我們關注的重點，下文對兩者進行詳細說明。

單元測試

單元測試是開發者編寫的一小段**，用於檢驗目標**的乙個很小的、很明確的功能是否正確。通常而言，乙個單元測試用於判斷某個特定條件或特定場景下某個特定函式的行為。例如，使用者可能把乙個很大的值放入乙個有序list中，然後確認該值出現在list的尾部。或者，使用者可能會從字串中刪除匹配某種模式的字元，然後確認字串確實不再包含這些字元了。

單元測試是由程式設計師自己來完成，最終受益的也是程式設計師自己。可以這麼說，程式設計師有責任編寫功能**，同時也就有責任為自己的**編寫單元測試。執行單元測試，就是為了證明這段**的行為和我們期望的一致。

在一般情況下，乙個功能模組往往會呼叫其他功能模組完成某項功能，如業務層的業務類可能會呼叫多個dao完成某項業務。對某個功能模組進行單元測試時，我們希望遮蔽對外在功能模組的依賴，以便將焦點放在目標功能模組的測試上。這時模擬物件將是最有力的工具，它根據外在模組的介面模擬特定操作行為，這樣單元測試就可以在假設關聯模組正確工作的情況下驗證本模組邏輯的正確性了。

整合測試

單元測試和開發工作是並駕齊驅的工作，甚至是前置性的工作。除了一些顯而易見的功能外，大部分功能（類的方法）都必須進行單元測試，通過單元測試可以保障功能模組的正確性。而整合測試則是在功能模組開發完成後，為驗證功能模組之間匹配呼叫的正確性而進行的測試。在單元測試時，往往需要通過模擬物件遮蔽外在模組的依賴，而整合測試恰恰是要驗證模組之間整合後的正確性。

舉個例子，當對userservice這個業務層的類進行單元測試時，可以通過建立userdao、loginlogdao模擬物件，在假設dao類正確工作的情況下對userservice進行測試。而對userservice進行整合測試時，則應該注入真實的userdao和loginlogdao進行測試。

所以一般來講，整合測試面向的層面要更高一些，一般對業務層和web層進行整合測試，單元測試則面向一些功能單一的類（如字串格式化工具類、資料計算類）。當然，我們可能對某乙個類既進行單元測試又進行整合測試，如userservice在模組開發期間進行單元測試，而在關聯的dao類開發完成後，再進行整合測試。

測試好處

在編寫**的過程中，一定會反覆除錯保證它能夠編譯通過。但**通過編譯，只是說明了它的語法正確。無法保證它的語義也一定正確，沒有任何人可以輕易承諾這段**的行為一定是正確的。幸運的是，單元測試會為我們的承諾做保證。編寫單元測試就是用來驗證這段**的行為是否與我們期望的一致。有了單元測試，我們可以自信地交付自己的**，減少後顧之憂。總之進行單元測試，會帶來以下好處：

— 軟體質量最簡單、最有效的保證；

— 是目標**最清晰、最有效的文件；

— 可以優化目標**的設計；

— 是**重構的保障；

— 是回歸測試和持續整合的基石。

——本段文字節選自《spring 3.x 企業應用開發實戰》一書

圖書詳細資訊:

為什麼需要單元測試

為什麼需要單元測試

為什麼需要單元測試

為什麼要做單元測試

相關推薦