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

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

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

為什么測試會不利？如何設(shè)計測試系統(tǒng)？

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

我們將描述一些可能有助于我們測試系統(tǒng)設(shè)計的方法和策略：

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

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

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

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

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

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

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

一些前端測試庫回顧

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

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

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

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

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

結(jié)論

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

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