持續內建之路——服務層的單元測試

        在完成了資料通路層的單元之後，接下來看如何編寫服務層（Service）的單元測試。服務層應該是整個系統中得重中之重，嚴密的業務邏輯設計保證了系統穩定運作，是以這一層的單元測試也應該占很大比重。雖然一般情況下單元測試應該盡量通過mock剝離依賴，但是由于在目前的項目中資料通路層使用spring-data架構，并沒有包含太多的邏輯，是以我就把服務層和資料通路層放在做了一個僞單元測試。

        一、一般邏輯的單元測試。

        這裡采用的方式和資料通路層幾乎是一樣的，主要包含三步：

        1. 通過@DatabaseSetup指定測試用資料集

        2. 執行被測試方法

        3. 通過Dao從資料庫中查詢資料驗證執行結果

        假設要被測試的代碼方法是：

其對應的接口是：

        這段邏輯代碼的意思十分簡單和直白，那麼要編寫的單元的測試必須要包含所有分支情況：a. 商場和樓層資訊都存在的，抛出異常 b. 商場存在，而樓層不存在, 樓層資訊都被添加的。 c.  商場和樓層都不存在，全部新增。這裡就以第一種情況為例，先準備測試資料：

接着編寫測試用例，注意要必須得注解不能忘掉：

這個測試和資料通路層的測試看起來沒有什麼兩樣。

        二、使用Mock對象隔離第三方接口

        軟體開發中一般都存在和第三方內建的情況，比如調用新浪的認證、百度的地圖等等。那麼在編寫測試的時候，基于效率的考慮，一般情況不會真的去調用這些遠端API（當然應該有其他測試可以及時發現第三方接口的變化），而是假定它們一直會傳回預期的結果。這個時候就需要用到mock對象，來模拟這些API産生相應的結果。

 其中thirdPartyAPI就是第三方用來認證的API。下面來看測試代碼：

      其實服務層的測試并沒有太多的新東西，而最關鍵的問題是如何把邏輯中各個分支都能測試到，使測試真正起到為軟體品質保駕護航的作用。