今天討論主題很重要，但也很容易被忽略的－－測試範圍。一份軟體會有許多不同種類的測試，它們會有測試可以確保的部分，而這些部分跟測試的範圍是有直接關係的。因此，知道測試的範圍，就知道確保的部分。

那知道這些能幹嘛呢？理由也很簡單：不管再怎麼調校，測試都是需要成本的。手動測試要人力和時間先別提，自動化測試執行的時間成本極小，但仍需撰寫成本和維護成本。既然有成本，接下來就會開始考慮優先權，哪些測試要先做，哪些後面再做。考慮這些的因素都會和測試確保的部分有關。

以下介紹各種測試的範圍與確保的部分。

這邊只介紹 Functional Testing ，也就是測試的目的是確保功能正確。

單元測試

單元測試主要測試元件獨立運作的正確性，但不測元件間的互動，即使是使用 Test Double ，它依然也算單元測試。單元測試的範圍僅限單元內部的運作，雖然範圍極小，但它的執行速度快、撰寫容易、維護成本低（沒亂用 Test Double 的話），所以它佔所有測試比例通常是最高的。

整合測試

整合測試測單元間的互動，但它通常不會管各單元是不是正確的。整合測試會有兩種可能，一種是 service 內部元件的整合，另一種是使用外部 service 如資料庫。前者的撰寫與維護成本都不高，通常建議可以不使用 Test Double 直接測；後者會有初始化的問題，執行時間會比較長，也比較不好寫。通常這類測試數量較少一點，而且也會另外建一個測試群組，待速度快的單元測試執行完畢後，再執行速度慢的整合測試。

測試有真的存取外部 server 時，表示測試範圍有觸及外部 server ，這時就可以確保元件到外部 server 的正確性。

API 測試

API 測試也是整合測試，它主要要整合程式與對外接口，如 HTTP 。通常這一類測試如果有對外依賴，都會做初始化，這樣就能確保 API 呼叫一直到對外部 server 存取過程的正確性。

E2E 測試

E2E 測試屬於使用者行為測試，如果是 Web 介面，代表它的範圍是從瀏覽器元素一直到後端服務。另外它也通常會測試排版與動態效果。

前端測試

將前端的元件視為單元的話，前端也會有單元測試的概念。通常前端單元測試都很單純，比較複雜會在整合測試，也就是前端的互動與後端 API 呼叫連結是否正確。前端整合測試也是用 Spy 的一個很好的範例。

今日回顧

根據莫非定律：「凡是可能出錯的事必定會出錯」，所以各種測試都有它存在的必要性。千萬不要有「單元測試夠多了，不需要整合測試」之類的想法。記得，它們驗證的目標和測試範圍都是不同的。

另外要注意的是，只要有使用 Test Double ，代表它不在測試範圍裡。不能 Mock 用的很開心，然後說測試都測過了。假的！記得 Test Double 是假的，所以測出來只是單元本身正確而已，最後還是要靠整合測試來驗證。

相關連結