UI 測試簡介
測試 UI 很麻煩。使用者期望頻繁發布且功能豐富的版本。但每個新功能都會引入更多 UI 和新的狀態，而您必須對這些進行測試。每個測試工具都承諾「簡單、不脆弱、快速」，但在細則中都有權衡取捨。
領先的前端團隊如何跟上進度？他們的測試策略是什麼，他們使用哪些方法？我研究了 Storybook 社群的十個團隊，以了解哪些方法有效——包括 Twilio、Adobe、Peloton、Shopify 等。
本指南重點介紹了規模化工程團隊使用的 UI 測試技術。您將學習如何實施務實的測試策略，以平衡覆蓋率、設定和維護。一路上，我會指出要避免的陷阱。
哪些需要測試？
所有主要的 JavaScript 框架都是元件驅動的。這表示 UI 是從「由下而上」建構的，從原子元件開始，逐步組合為頁面。
請記住，每個 UI 部分現在都是一個元件。沒錯，包括頁面。頁面和按鈕之間唯一的區別在於它們如何消耗資料。
因此，測試 UI 現在與測試元件是同義詞。
各種測試方法（單元、整合、e2e）之間的區別對於元件來說可能很模糊。相反地，讓我們專注於我們可以測試的 UI 的不同特性。
視覺化
視覺化測試驗證元件在給定一組 props 和 state 的情況下是否正確渲染。它們的工作原理是拍攝每個元件的螢幕截圖，並將它們逐次提交進行比較，以識別變更。
組合
元件是相互連接的，資料在它們之間流動。您可以透過對更高等級的元件和頁面執行視覺化測試來驗證這種整合。
互動
互動測試驗證事件是否按預期處理。它們首先在隔離狀態下渲染元件。然後模擬使用者行為，例如點擊或輸入。最後，驗證狀態是否已正確更新。
無障礙功能
無障礙功能測試揭示與視覺、聽覺、行動和其他障礙相關的可用性問題。使用 Axe 等自動化工具作為 QA 的第一道防線，以捕獲明顯的無障礙功能違規行為。然後在真實裝置上進行手動 QA，以解決需要人工注意的棘手問題。
使用者流程
即使是最基本的任務也需要使用者完成跨多個元件的一系列步驟。這又是另一個潛在的故障點。Cypress 和 Playwright 等工具允許您針對完整的應用程式執行測試，以驗證此類互動。
了解工作流程
我們已經涵蓋了需要測試的 UI 的不同方面，但了解如何將它們組合成高效的工作流程是很棘手的。如果您弄錯了，UI 開發流程會感覺像是一場苦戰。每當實作有調整時，您的測試就會失敗。您必須為每個工具複製測試案例，而這一切都會演變成維護噩夢。
我採訪的團隊儘管規模和技術堆疊不同，但都採用了類似的策略。我已將這些學習提煉成這個務實的工作流程
- 📚 **使用** Storybook **隔離元件**。編寫測試案例，在其中使用 props 和模擬資料重現每個狀態。
- ✅ **使用** Chromatic **捕捉視覺錯誤並驗證組合**。
- 🐙 **使用** Vitest 和 Testing Library **驗證互動**。
- ♿️ **使用** Axe **稽核元件的無障礙功能**。
- 🔄 **透過使用** Cypress **編寫端對端測試來驗證使用者流程**。
- 🚥 **透過使用** GitHub Actions **自動執行測試來捕捉回歸錯誤**。
讓我們開始測試吧
在接下來的章節中，我們將更深入地探討測試堆疊的每一層，並深入了解實施此測試策略的機制。但首先，我們需要一些東西來測試。我將以 Taskbox 應用程式為例。它是一個類似於 Asana 的任務管理應用程式。
請注意，實作細節並不重要，因為我們更專注於如何測試這個 UI。我們在這裡使用 React，但請放心；這些測試概念適用於所有基於元件的框架。
若要取得程式碼，請執行以下命令
# Clone the template
npx degit chromaui/ui-testing-handbook-react-template ui-testing-guide-code
cd ui-testing-guide-code
# Install dependencies
yarn
初始化一個新的 GitHub 儲存庫，並將其與您的本機專案同步。
git init
git add .
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/<your username>/ui-testing-guide-code.git
git push -u origin main