我(wǒ)們在制作好網站的前端後都需要進行測試，這是網站建設過程非常重要的一(yī)個環節，前端測試僅僅是工(gōng)具和過程。在本文中(zhōng)尼高小(xiǎo)編将分(fēn)享他關于如何組織測試以及在前端和子系統之間以及不同策略之間找到正确平衡的經驗。

我(wǒ)經常遇到前端開發人員、管理人員和團隊面臨一(yī)個重複且合理的困難困境：如何在單元、集成和E2E測試之間組織他們的測試，以及如何測試他們的UI組件。單元測試似乎經常不能捕捉到發生(shēng)在用戶和系統身上的“有趣”的事情，E2E測試通常需要很長時間來運行或者需要一(yī)個混亂的配置。

我(wǒ)們不傾向于把我(wǒ)們的前端設計成一(yī)個系統，而是一(yī)堆組成用戶界面故事的組件和功能。由于組件代碼主要存在于JavaScript或JSX中(zhōng)，而不是在HTML、JS和CSS之間分(fēn)離，混合視圖代碼和業務邏輯代碼也比以往任何時候都更有吸引力。當我(wǒ)說“我(wǒ)們”時，我(wǒ)指的是我(wǒ)作爲開發人員或顧問遇到的幾乎每一(yī)個web項目。

當我(wǒ)們來測試這段代碼時，我(wǒ)們通常從類似反應測試庫它渲染React組件并測試結果，或者我(wǒ)們爲配置Cypress使其與我(wǒ)們的項目很好地配合而煩惱，很多時候以錯誤配置或放(fàng)棄而告終。當我(wǒ)們與管理人員談論建立前端測試系統所需的時間時，他們和我(wǒ)們都不知(zhī)道它需要什麽，我(wǒ)們在那裏的努力是否會有成果，以及我(wǒ)們構建的任何東西如何對最終産品的質量和構建速度有價值。

如果我(wǒ)們有某種"強制TDD "團隊中(zhōng)的(測試驅動開發)過程，或者更糟，一(yī)個代碼覆蓋門，你必須有X%的代碼被測試覆蓋。作爲前端開發人員，我(wǒ)們結束了一(yī)天的工(gōng)作，通過修複散布在幾個React組件、定制挂鈎和Redux reducers之間的幾行代碼來修複一(yī)個bug，然後我(wǒ)們需要提出一(yī)個“TDD”測試來“覆蓋”我(wǒ)們所做的事情。當然這不是TDD在TDD中(zhōng)，我(wǒ)們會先編寫一(yī)個失敗的測試。但是在我(wǒ)遇到的大(dà)多數前端系統中(zhōng)，沒有基礎設施來做這樣的事情，并且在試圖修複關鍵bug的同時首先編寫失敗測試的請求通常是不現實的。

爲了尊重我(wǒ)們組織的過程，像強制測試規則或CI中(zhōng)的一(yī)些代碼覆蓋門，我(wǒ)們使用Jest或我(wǒ)們手邊的任何工(gōng)具，模仿我(wǒ)們已經改變的代碼庫部分(fēn)周圍的一(yī)切，并添加一(yī)個或多個“單元”測試，以驗證它現在給出“正确”的結果。

除了測試難以編寫之外(wài)，它的問題是我(wǒ)們現在已經創建了一(yī)個事實上的合同。我(wǒ)們不僅驗證了一(yī)個函數給出了一(yī)些預期的結果，而且我(wǒ)們還驗證了這個函數具有測試預期的簽名，并且以與我(wǒ)們的模拟相同的方式使用環境。如果我(wǒ)們想要重構那個函數簽名或者它如何使用環境，測試将成爲一(yī)個累贅，一(yī)個我(wǒ)們不打算遵守的契約。它可能會失敗，即使該功能有效，也可能會成功，因爲我(wǒ)們改變了内部的一(yī)些東西，并且模拟環境不再與真實環境匹配。