如何於 2026 年建構前端自動化測試

前言

前端測試一直存在龐大的需求，但具體討論如何實戰中建構合理測試體制的討論文章卻不多，隨著社群工具成熟與不同的嘗試下我摸索出一套實戰可採用的方式替團隊建構設施。

如何技術選型

選擇某項解決方案之前必須知道自己選擇的原因以及未來的走向，特別是在網頁領域，有太多已經被淘汰的技術與陳舊代碼

前端環境複雜程度是無庸置疑的高，不同的瀏覽器、版本、裝置尺寸、開發環境⋯⋯就連工具鏈也經歷過許多次的迭代，像是： Gulp🔗 > Webpack🔗 > Vite🔗。選擇比努力重要，把投入花在對的方向，根據社群的反饋與統計做判斷。

• JavaScript Survey🔗
• 對前端生態有敏銳度，追社群中主要的影響者與討論（YouTube、Hacker News🔗、daily.dev🔗）
• 了解與評估解決方案之間的取捨
• 翻閱官方文件（Vue testing🔗、React Testing🔗）

雖然在網頁開發領域沒有技術是持久不變的，但根據問卷調查🔗與社群趨勢來看，大量成熟的 Meta-Framwork （Nuxt、SvelteKit、SolidStart、Astro、Vitest、Storybook）與生態被建立在 Vite 之上，在 2026 如果撰寫網頁絕對會碰到或是基於 Vite 生態，恰巧我的工作與日常專案上也都是基於 Vite，所以會大量的偏袒這個生態以及相關概念會影響後續的決策。但假如說你在 Angular、Next 這樣自成體系的生態中，又是另一個故事了。

根據以上的評估，目前我的 Stack 如下：

• Vitest🔗
• Mock Service Worker🔗
• Playwright🔗
• Storybook🔗

測試之前

研究如何撰寫有效有意義的測試

• 釐清產品的性質、測試著重的重點（toC 視覺 / toB？ 功能性）
• 了解測試的種類與術語（你需要知道的软件测试类型和常识🔗）
• 了解測試的通則（如何保持測試的韌性、了解 Flaky Test 的成因與如何避免）
• 怎麼確保團隊能穩定的導入測試流程（準備測試入門文件HowToTesting.md）
• 測試怎麼保持反饋？（於 CI？ 於 Git Hooks？）
• 規劃如何付出最小的代價帶來最大的收益？（如何導入 AI 降低測試成本？）

要考慮的很多，所以我會假設一個最基礎實際的問題開始，先不考慮陳舊代碼的問題：「假如我是剛加入這個專案的成員，撰寫一個新功能時要如何添加測試？」、「測試如何對團隊產生收益？」，這時候就會發現缺了什麼環境、少了文件、流程有缺失或不符合效益的問題都會顯現，再一步一步思考如何解決。

建構測試環境

要進行前端測試有一些特殊的前置知識：

• JavaScript 有兩種運行環境：Nodejs🔗 與瀏覽器。
• 可以用 JSDOM🔗 或 HappyDOM🔗 在 Node.js 模擬瀏覽器環境，會慢一些且可能會有模擬不到位的問題，好處是不需要設置真實的瀏覽器環境。
• 傳統 E2E 測試解決方案是啟動真實的 headless 瀏覽器模擬以「頁面」為單位來測試，但隨著工具進步渲染特定前端框架元件也變得可行：Vitest Browser Mode🔗、Cypress Component Testing🔗、Playwright Components🔗。

為什麼我會選擇 Vitest Browser Mode 是因為：

1. 主流的開源測試工具。
2. 相同工具與 API 測試不同種類的前端代碼。可以使用同個 Test Runner 創建不同的環境（Projects🔗），接上不同 Vite 環境、瀏覽器引擎。像是我會設置不同名稱的檔案對應測試環境： Foo.browser.test.ts、Foo.jsdom.test.ts、Foo.node.test.ts。
3. 我喜歡 Cypress 的整合體驗和完善的文件，但它給我感覺仍是封閉的技術，從進階功能付費到它們架構特有的 API：Cypress 與 Playwright 如何選擇？🔗
4. Playwright 支援作為 Browser Mode 引擎支援所有瀏覽器，且有超級直覺的 CI 設置體驗🔗。

啟動測試步驟

• 創建一個 HowToTesting.md 文件把踩到的坑、流程、能提升測試品質的案例都記錄下來，避免 AI 與接手的人犯下同樣的錯誤。
  • 使用 Gerkin🔗 語句結構的測試案例提升測試閱讀性。
  • 常見客製化元件的測試真實範例。
  • ⋯⋯
• 挑一個速度夠快夠便宜的 Coding Agent，測試需要面對大量的試錯與迭代，當前我覺得 Grok Fast 1🔗 體驗非常讚。
• 開始用嘴巴寫測試：

// 事先規劃測試案例
describe('Foobar.vue', () => {
  test.todo('Test Case A', () => {})
  test.todo('Test Case B', () => {})
  test.todo('Test Case C', () => {})

  // 也可以先跳過一項一項解決，避免 Context 過大
  test.only('Test Case C', () => {})
})

Base on @Foobar.vue finish @Foobar.browser.test.ts , you should reference @HowToTesting.md

總結

測試瓶頸不在於「熟悉特定框架」或「生態還不夠成熟」，在實戰中 90% 的測試代碼已經不用手動撰寫，測試的重心可以更好的分配在：

1. 釐清合理的測試的邊界與測試方式
2. 審核把關測試品質
3. 透過測試思考更合理的軟體架構

其他反思

怎麼看在 Storybook 裡面寫測試

Why I Don’t Like Storybook - Theo Throwaways🔗

經過多年的整合可以直接在裡面撰寫測試案例🔗。但我仍在觀望不採用：

1. 把測試又透過插件套在它們的格式上讓我感覺毛毛的，會不會哪天遷移不走？
2. 它們大力推動它們自家的平台與相關 Visual Testing 測試🔗，和 Cypress 一樣的預感。
3. Storybook 又是額外複雜的學習曲線與需要維護的專案，小團隊不太有用。

所以我只用最小的精力維持，請 AI 替元件生一些粗糙的 Story 紀錄作為活文件。

延伸閱讀

• 現代 bundler、build tool 簡介 - Code Farmer🔗
• JSDC 2020 - 用 API mocking 讓前端不再苦苦等待 | Huli🔗
• Why I Won’t Use JSDOM🔗