測試範圍

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

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

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

這邊只介紹 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 是假的,所以測出來只是單元本身正確而已,最後還是要靠整合測試來驗證。

相關連結