規劃測試策略 | 單元測試的藝術 第 3 版 | 閱讀筆記
04 Jun 2024「單元測試的藝術」讀書會 - 規劃測試策略 (The Art of Unit Testing, 3e - Developing a testing strategy) 閱讀筆記。
如何規劃測試的策略？
在規劃測試策略時，單元測試、元件測試、整合測試、API 測試與端對端測試的比例應是多少？哪些測試能給予怎樣程度的信心？能給予哪樣程度的回饋？通常來說，愈高等級的測試，愈能給予更高程度的信心，但也愈耗時；愈低等級的測試，愈能給予更快的回饋，以及最具體的錯誤訊息，但給予愈低程度的信心。
注意：
- 由於 E2E 測試的重複性高，因此邊際效益遞減很快，建議盡量減少 E2E 測試的數量；單元測試可以測到更多不同的場景，因此單元測試的邊際效益遞減較慢。雖然兩者都是必要的，但盡量減少 E2E 測試的數量，也就是只需進行一些涵蓋最重要功能的 E2E 測試即可。
- 關於重複測試該怎麼處理？在團隊合作中，RD 和 QA 必須是一體的，讓開發人員實作較低層級的測試，而 QA 將專注於實作較高層級的測試，這樣 RD 和 QA 之間就不會有重複的測試，也能同時進行開發。
關於測試策略該怎麼規劃，推薦閱讀：Pyramid or Crab? Find a testing strategy that fits - 總結這篇文章的重點，產品規模較大時，需要與不同元件、產品或服務整合，以確保功能正常，因此，integration testing 的比例會比較高。反之，若產品規模較小、功能單純，此時要檢驗的大多是自身功能，unit testing 的比例就會比較高。
舉例來說，UI library 要確認品質，可以使用單元測試，包含基本的元件測試和視覺測試；而一般的專案可安排更全面的測試，除了顆粒度小、能測試更多細節的單元測試之外，還可以加上整合測試、端對端測試來確保關鍵的互動路徑能正確被執行。
Delivery-blocking vs Non-blocking Tests
在建立 build 的管道時，可以將測試分為兩類：交付阻塞測試 (delivery-blocking test) 和非阻塞測試 (non-delivery-blocking test)。交付阻塞測試是必要的，如果失敗，則停止交付被測程式碼，必須將問題解決後才能繼續交付、進而部署、上線；非阻塞測試是可選的，如果失敗，則不會停止交付被測程式碼，但仍然會提供回饋，讓開發人員知道問題所在，並且可在之後解決，build 可以被部署、上線。
Delivery vs Discovery Pipelines
承上，將建置管道分為交付管道 (delivery pipeline) 和發現管道 (discovery pipeline)。交付管道應用於交付阻塞測試，如果失敗，則停止交付被測程式碼。發現管道用於發現問題，並與交付管道並行執行。除了平行執行管道，還可以平行執行管道內的階段，甚至可以平行執行階段內的測試。
Test Parallelization
除了平行執行管道外，還可以平行執行測試。例如，如果遇到大量 E2E 測試，可以將它們分解為平行測試套件，這樣可以節省大量時間。
