根據 Bob 大叔的說法，測試是系統的一部分；許多開發人員認為相反，因為他們沒有部署。他宣稱這是一個災難性的觀點，因為測試的作用是支持開發并保持系統的健壯性和易于更改。

在前端，通常會測試最終用戶與我們應用程序的交互。我們應該向用戶保證，當他們登錄、打開彈出窗口、添加評論或與我們的應用程序進行任何其他交互時，不會遇到任何錯誤和不愉快的體驗。

在前端進行測試，如果正確完成，將使我們的用戶感到滿意，并在使用我們的應用程序時獲得良好的性能體驗。另一方面，對于開發者來說，會節省大量的時間去解決bug，或者在添加新特性的時候，不會破壞代碼之前的行為。

為什么測試會不利？如何設計測試系統？

測試需要時間，也需要與開發過程中的變化保持一致。此外，隨著設備和瀏覽器的發展，我們需要與時俱進。在軟件測試中，有一個稱為脆弱測試問題的概念。這可以定義為導致數百個測試失敗的系統中的一個更改。Bob 大叔強調了設計良好的測試系統對于我們系統的穩定性和回歸的預期好處的重要性（Clean Architecture，Robert C. Martin，2018）。

我們將描述一些可能有助于我們測試系統設計的方法和策略：

Martin Fowler 在他的文章“關于測試的多樣化和奇異的形式”中講述了當他們向測試專家詢問單元測試的定義時他的那一刻。他說，這位專家的回答是，他在培訓課程的第一天早上就涵蓋了 24 種不同的單元測試定義。由于單元測試有許多不同的定義，在本文中，我們將包括 Fowler 稱為單獨測試的一種。

在著名的測試金字塔中，在底部，我們遇到了測試覆蓋率較低但執行速度最快的單元測試。在第二層，我們看到了集成測試，它的覆蓋率更高，但速度較慢，因為它可能會連接到外部部件。最后，我們有 E2E 測試或一些呼叫驗收測試，它們覆蓋了應用程序的很大一部分，但它們執行起來最慢。

單元測試單獨檢查我們的組件是否正常工作。它們還涵蓋了要測試的邊緣案例，這使我們的代碼庫更加可靠。單元測試之后是集成測試的實施。集成測試檢查相互連接時獨立開發的兩個軟件單元或模塊之間的通信。他們分析系統連接時的行為，并檢查微服務之間的交互。它們還包括 API 連接，這就是為什么它們在單元測試方面速度較慢的原因，因為連接可能會延遲，或者服務可能會關閉。在前端，集成測試用于檢查返回 API 的數據是否具有正確的對象、數組或格式。

E2E 測試模擬用戶行為并檢查用戶與我們應用程序的所有交互。它們是在真實瀏覽器中執行的集成測試的專門版本。它們通常在合并或發布之前運行，因為完成測試的執行可能需要數小時。

在下文中，我們還提到了測試技術，例如 Accessibility 和 UI：

可訪問性測試檢查用戶界面是否可供每個用戶輕松使用，并使我們的應用程序可用于殘障人士。Jest-axe 是一個很棒的 Jest 測試庫，它允許我們檢查應用程序的可訪問性。

UI 測試檢查我們應用程序的用戶界面是否正常工作。如果用戶輸入內容、單擊復選框或刪除元素，應該可以正常工作并按預期更新 UI 狀態。

一些前端測試庫回顧

Jest 是一個主要用于前端單元和集成測試的庫。由于其巧妙的并行測試機制實現，對于測試文件較多的大型項目來說速度非常快。

測試庫是一個我們可以編寫單元和集成測試的庫。它有助于方便的選擇器、觸發事件、配置、處理異步代碼等等。

Cypress 是一個將其測試注入 Cypress.io 在瀏覽器中自行運行的網站的庫。我們可以高效地編寫單元、集成和端到端測試。

它為開發者提供了更快的體驗，我們可以很容易地在它的瀏覽器上看到錯誤。

Applitools 用于視覺回歸測試。憑借其先進的 AI 技術，它可以檢測圖像和 DOM 之間的差異。檢查我們網站的外觀是否與前一個相同或是否發生錯誤非常有用。此外，如果用戶在移動設備或網絡上可以正確看到網站上的任何項目或按鈕，它還會檢查不同的瀏覽器和平臺。

結論

前端測試應該是我們開發的一部分，以便在代碼投入生產之前解決代碼中的問題。我們應該編寫單元測試來檢查我們應用程序中的每個功能，還應該開發集成測試來檢查所有組件和模塊是否一起正常工作。另一方面，我們應該編寫 E2E 測試來自動化手動點擊測試，并以用戶與我們的應用程序交互的方式為中心。

我們應該編寫測試來提供信心，而不僅僅是改進指標。正如 Robert C. Martin 所說，我們應該避免編寫與系統強耦合的測試。因為即使是最微不足道的更改也會導致許多測試中斷。