有效的前端測試

面試已經有一段時間了。在這個痛苦的過程中最突出的是，如果提出測試問題，面試就注定失敗。這是因為我的經驗主要是前端開發，而我待過的兩家公司在前端測試方面都很糟糕。

--- 如果想直接進入討論請跳過 ---

從某種意義上說，我的缺乏是產業文化的副產品。前端測試一直是一件事，但十年前，公司結構已經將測試問題與開發過程分開。因此，我們有一個專門的 QA 團隊，他們將為我們的開發人員編寫 E2E/自動化測試。所以測試甚至沒有出現在工作描述中。此外，小型新創公司的不幸事實是交付始終高於一切，因此由於測試會阻礙生產力，因此我們開發人員沒有進行測試。我們甚至沒有在儲存庫中安裝任何測試庫（Jasmine/Mocha/PhantomJS...）。

我在一家更大的公司找到了第二份工作（消費者平台團隊有大約 150 名開發人員？）。然而，從本質上講，並沒有進行任何測試。每個團隊（按結帳、忠誠度、註冊等功能劃分的團隊）再次有專門的 QA 成員來編寫這些 E2E 測試。一旦這種文化形成並且品質保證從預算中削減，就沒有人接受它們，因為沒有人可以向他們學習。我試圖為我們的團隊進行一些 E2E 測試，但留下的程式碼甚至無法正常工作，而且充滿了明顯的錯誤（很多 WTF）。再加上時間緊迫，測試又落後了。人們談論測試的唯一一次是實用函數和自訂反應掛鉤。

---討論開始---

受到無測試文化的困擾，我至少必須想出一些我可以在面試中抽像地談論測試的東西。我將跳過不測試樣式或實現之類的常見廢話。

請隨意加入討論。這影響了我至少 300 位過去的同事！

1.) 測試全域狀態：
根據我的經驗，最粗糙的功能之一是「如果發生這種情況，我們會自動為您執行此操作」類型的行為。例如，我擁有的一個應用程式是一個可高度配置的圖形視覺化儀表板。一項配置更改可能會導致其他配置也發生更改，具體取決於返回的資料以及未返回的資料。有些配置副作用並不直接。因此，您需要測試自動配置變更以及狀態是否全面持久/未變更/一致。因此，如果您圍繞此類行為進行測試，與 PM、經理、設計和 QA 團隊保持一致是非常有價值的。

2.）不要花太多時間測試 UI 輸入的完整性：
我看到很多教程都在談論測試輸入，例如當我在搜尋欄中輸入“泰勒·斯威夫特”並按 Enter 鍵時，我們的搜尋功能將獲得泰勒·斯威夫特作為輸入。

這毫無幫助。如果您的資料綁定被破壞，那麼很明顯您應該在開發時自己捕獲它，或者它不能自動測試，因為某些東西阻礙了功能，例如搜尋欄上方的不可見 div，因此用戶無法輸入搜尋。

如果你是透過程式碼行付費的，那就繼續吧:)

3.）測試輸入作為輸入的副作用是可取的：
與第二點相反，您需要測試對使用者互動完全產生副作用的功能呼叫。例如，當使用者點擊按鈕時，應該呼叫一個請求來註冊該使用者操作以進行資料分析。這種與核心功能完全分離的副作用應該自動測試，這樣我們就不會因為一些無意的更改而措手不及。非核心副作用對其他團隊來說可能至關重要，我曾在其他團隊之一中工作：D

那麼如何建構這些測驗需求呢？
讓我們分解一下前端架構：MVC（你可以說你是 MVVM 或什麼不是，這並不重要）。

V - 視圖 (html/jsx)： 這非常適合 E2E/無頭瀏覽器測試，並且是業界標準。

C - 控制器（業務邏輯）：花一些時間確保功能正確。例如，如果您具有/抽象化為純函數，那麼預期的輸入輸出過程是否仍然完好無損？有點行業標準，但人們通常不會費心將有狀態函數變成純函數並進行測試。

M - 模型（api 呼叫/狀態）： 這是我最想關注的。您的（非渲染）狀態應該是全域的並且每個概念都是單例的。這不是什麼新想法，因為 Redux 基本上就是這樣。然而，出於我們的測試目的，它不一定是 Flux。您可以擁有 jotai 原子，但您可以編寫一個包裝器，以便可以公開集中的 setter 函數進行測試。

應該在您的 api 呼叫/第三方程式庫上執行類似的操作。它應該是全局的和單例的，以便您可以自信地測試“當我這樣做時，是應用程式中進行的核心/非核心 api 調用”。以我有限的經驗，這是在後端應用程式中例行完成的。它也應該在前端應用程式中完成。

這聽起來怎麼樣？我確信已經有人這麼做了，你的經驗是什麼？有什麼可以改進的？我很想聽聽人們的意見，他們認為前端測試不僅僅是 E2E/無頭瀏覽器和簡單的單元測試。

以上是有效的前端測試的詳細內容。更多資訊請關注PHP中文網其他相關文章！