探討單元測試和整合測試的涵蓋範圍
本篇文章紀錄自己導入 測試驅動開發（Test Driven Design） 過程中，曾經沒辦法分辨自己所寫的測試案例到底是“單元測試”還是“整合測試”，與同儕討論後發現其他人也有相同的困擾，於是看了幾本書與文章才釐清自己的問題所在。為方便與其他人進行交流討論，故將自己理解的資訊整理下來並做個總結。 單元測試的涵蓋範圍很模糊？ 單元測試（Unit Test）是軟體開發中很重要的環節，替 TDD 提供重構的保護網，也是軟體測試（Software Testing）中測試金字塔（Test Pyramid）的最低測試層級。 但是，一個「單元測試」所涵蓋的範圍到底有哪些，卻讓國外網友議論紛！ 大家在初學單元測試一定會看到的定義如下： 以程式碼的最小單位來進行正確性檢驗的測試工作，最小單位包括「類別與方法」。 若按此定義來寫測試案例，一個單元測試只能包含一個類別。且受測類別的依賴都必須透過測試替身或 Mock 技術進行隔離，才能確保測試的目標是最小且不可分割的邏輯。 但是隨著 Mock 的詬病被發掘（參考： Mock 不是測試的銀彈 ），為避免 Mock 使測試案例變成開發人員的快樂表（測試通過，正式環境卻出現錯誤），開始有人提倡使用 Spy 來替代 Mock，以及依賴若是自己的開發團隊所寫，而非第三方函式庫，則可直接使用依賴。 這時，一個單元測試會執行的範圍已經從 一個類別 變成 一個類別加上該類別的依賴 。換句話說，一個單元測試除了受測程式外，也會執行到其他類別的程式碼： describe( 'AddGroupToRange' , function () { it( '空的統計範圍, 將題組「questionGroups1」新增至空的統計範圍中, 統計範圍包含題組「questionGroups1」' , function () { // @given 空的統計範圍 var range = new StatisticsRange(); var pipeline = new Pipeline(range); // @when 將題組「questionGroups1」新增至空的統計範圍中 pipe
