我們在制作好網(wǎng)站的前端后都需要進行測試，這是網(wǎng)站建設過程非常重要的一個環(huán)節(jié)，前端測試僅僅是工具和過程。在本文中尼高小編將分享他關(guān)于如何組織測試以及在前端和子系統(tǒng)之間以及不同策略之間找到正確平衡的經(jīng)驗。

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

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

當我們來測試這段代碼時，我們通常從類似反應測試庫它渲染React組件并測試結(jié)果，或者我們?yōu)榕渲肅ypress使其與我們的項目很好地配合而煩惱，很多時候以錯誤配置或放棄而告終。當我們與管理人員談論建立前端測試系統(tǒng)所需的時間時，他們和我們都不知道它需要什么，我們在那里的努力是否會有成果，以及我們構(gòu)建的任何東西如何對最終產(chǎn)品的質(zhì)量和構(gòu)建速度有價值。

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

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

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