我們在制作好網站的前端后都需要進行測試，這是網站建設過程非常重要的一個環節，前端測試僅僅是工具和過程。在本文中尼高小編將分享他關于如何組織測試以及在前端和子系統之間以及不同策略之間找到正確平衡的經驗。
我經常遇到前端開發人員、管理人員和團隊面臨一個重復且合理的困難困境：如何在單元、集成和E2E測試之間組織他們的測試，以及如何測試他們的UI組件。單元測試似乎經常不能捕捉到發生在用戶和系統身上的“有趣”的事情，E2E測試通常需要很長時間來運行或者需要一個混亂的配置。
我們不傾向于把我們的前端設計成一個系統，而是一堆組成用戶界面故事的組件和功能。由于組件代碼主要存在于JavaScript或JSX中，而不是在HTML、JS和CSS之間分離，混合視圖代碼和業務邏輯代碼也比以往任何時候都更有吸引力。當我說“我們”時，我指的是我作為開發人員或顧問遇到的幾乎每一個web項目。
當我們來測試這段代碼時，我們通常從類似反應測試庫它渲染React組件并測試結果，或者我們為配置Cypress使其與我們的項目很好地配合而煩惱，很多時候以錯誤配置或放棄而告終。當我們與管理人員談論建立前端測試系統所需的時間時，他們和我們都不知道它需要什么，我們在那里的努力是否會有成果，以及我們構建的任何東西如何對最終產品的質量和構建速度有價值。
如果我們有某種"強制TDD "團隊中的(測試驅動開發)過程，或者更糟，一個代碼覆蓋門，你必須有X%的代碼被測試覆蓋。作為前端開發人員，我們結束了一天的工作，通過修復散布在幾個React組件、定制掛鉤和Redux reducers之間的幾行代碼來修復一個bug，然后我們需要提出一個“TDD”測試來“覆蓋”我們所做的事情。當然這不是TDD在TDD中，我們會先編寫一個失敗的測試。但是在我遇到的大多數前端系統中，沒有基礎設施來做這樣的事情，并且在試圖修復關鍵bug的同時首先編寫失敗測試的請求通常是不現實的。
為了尊重我們組織的過程，像強制測試規則或CI中的一些代碼覆蓋門，我們使用Jest或我們手邊的任何工具，模仿我們已經改變的代碼庫部分周圍的一切，并添加一個或多個“單元”測試，以驗證它現在給出“正確”的結果。
除了測試難以編寫之外，它的問題是我們現在已經創建了一個事實上的合同。我們不僅驗證了一個函數給出了一些預期的結果，而且我們還驗證了這個函數具有測試預期的簽名，并且以與我們的模擬相同的方式使用環境。如果我們想要重構那個函數簽名或者它如何使用環境，測試將成為一個累贅，一個我們不打算遵守的契約。它可能會失敗，即使該功能有效，也可能會成功，因為我們改變了內部的一些東西，并且模擬環境不再與真實環境匹配。
下一篇：網站設計系統優化
助企科技官網
