前端測(cè)試是網(wǎng)站建設(shè)過(guò)程中一個(gè)非常重要的環(huán)節(jié)，我們不傾向于將前端編寫(xiě)為一個(gè)系統(tǒng)，而是將其編寫(xiě)為構(gòu)成用戶界面故事的一組組件和功能。由于組件代碼主要存在于 JavaScript 或 JSX 中，而不是在 HTML、JS 和 CSS 之間分離，混合視圖代碼和業(yè)務(wù)邏輯代碼也比以往任何時(shí)候都更有吸引力。當(dāng)我說(shuō)“我們”時(shí)，我指的是我作為開(kāi)發(fā)人員或顧問(wèn)遇到的幾乎每個(gè)網(wǎng)站建設(shè)項(xiàng)目。


我經(jīng)常遇到前端開(kāi)發(fā)人員、管理人員和團(tuán)隊(duì)面臨重復(fù)且合理困難的困境：如何在單元、集成和 E2E 測(cè)試之間組織他們的測(cè)試，以及如何測(cè)試他們的 UI 組件。當(dāng)我們開(kāi)始測(cè)試這段代碼時(shí)，我們通常從渲染 React 組件并測(cè)試結(jié)果的React 測(cè)試庫(kù)之類(lèi)的東西開(kāi)始，或者我們熱衷于配置 Cypress 以很好地與我們的項(xiàng)目一起工作，但很多時(shí)候最終會(huì)出現(xiàn)配置錯(cuò)誤或放棄。當(dāng)我們與管理人員談?wù)摻⑶岸藴y(cè)試系統(tǒng)所需的時(shí)間時(shí)，他們和我們都不知道它究竟需要什么，我們?cè)谀抢锏呐κ欠駮?huì)取得成果，以及我們構(gòu)建的任何東西對(duì)測(cè)試質(zhì)量有何價(jià)值最終產(chǎn)品和建造速度。


如果我們?cè)趫F(tuán)隊(duì)中有某種“強(qiáng)制 TDD”（測(cè)試驅(qū)動(dòng)開(kāi)發(fā)）流程，或者更糟糕的是，有一個(gè)代碼覆蓋門(mén)，你必須讓 X% 的代碼被測(cè)試覆蓋，情況會(huì)變得更糟。我們以前端開(kāi)發(fā)人員的身份結(jié)束了這一天，通過(guò)修復(fù)散布在多個(gè) React 組件、自定義鉤子和 Redux reducer 中的幾行代碼來(lái)修復(fù)錯(cuò)誤，然后我們需要提出一個(gè)“TDD”測(cè)試來(lái)“覆蓋”什么我們做到了。在 TDD 中，我們會(huì)首先編寫(xiě)一個(gè)失敗的測(cè)試。但是在我遇到的大多數(shù)前端系統(tǒng)中，沒(méi)有基礎(chǔ)設(shè)施可以做這樣的事情，并且在嘗試修復(fù)關(guān)鍵錯(cuò)誤時(shí)首先編寫(xiě)失敗測(cè)試的請(qǐng)求通常是不現(xiàn)實(shí)的。

除了測(cè)試難以編寫(xiě)之外，它的問(wèn)題在于我們現(xiàn)在已經(jīng)創(chuàng)建了一個(gè)事實(shí)上的合約。我們不僅要驗(yàn)證一個(gè)函數(shù)是否給出了一些預(yù)期的結(jié)果，而且我們還要驗(yàn)證這個(gè)函數(shù)是否具有測(cè)試所期望的簽名，并以與我們的模擬模擬相同的方式使用環(huán)境。如果我們想要重構(gòu)該函數(shù)簽名或它如何使用環(huán)境，那么測(cè)試將變得沉重，這是我們不打算保留的合同。即使該功能有效，它也可能會(huì)失敗，它可能會(huì)成功，因?yàn)槲覀冊(cè)趦?nèi)部進(jìn)行了更改，并且模擬環(huán)境不再與真實(shí)環(huán)境匹配。