很多前端工程師都有這種經驗：
本機測試都正常，API 也沒問題，功能看起來完美，結果一部署到 staging 或 production 就開始出現奇怪 bug。
像是：
- 登入流程偶爾卡住
- 按鈕在某些瀏覽器無法點擊
- 表單送出後沒有跳轉
- 第三方登入 callback 壞掉
- 某個 modal 疊在 loading 上面導致整頁無法操作
這些問題其實有個共通點：
「單元測試測不到，但使用者一定會遇到。」
這也是為什麼近幾年 E2E（End to End）測試開始變成很多團隊的標準配備。
什麼是 E2E 測試？
E2E 測試的核心概念很簡單：
「模擬真實使用者操作整個系統。」
它不像 unit test 只測 function，也不像 integration test 只測模組整合。
E2E 是真的開瀏覽器、點按鈕、輸入資料、送出表單、等待 API 回應。
簡單來說：
它測的是「使用者到底能不能順利完成任務」。
例如：
test('使用者可以完成登入流程', async ({ page }) => {
await page.goto('https://example.com')
await page.fill('#email', '[email protected]')
await page.fill('#password', '123456')
await page.click('button[type=submit]')
await expect(page).toHaveURL('/dashboard')
})為什麼現在 E2E 越來越重要？
以前很多人不愛寫 E2E，原因很簡單：
- 難維護
- 跑很慢
- 很容易 flaky
- CI 很痛苦
但這幾年情況其實改變很多。
尤其是：
- Playwright
- Cypress
- Selenium
- Vitest Browser Mode
- Testing Library 生態
成熟度都高很多。
現在的 E2E 已經不像以前 Selenium 時代那麼痛苦。
目前 E2E 工具其實開始分成兩個世代
第一代比較像：
「測試 framework。」
例如：
- Playwright
- Cypress
- Selenium
- WebdriverIO
這類工具本質上還是：
「人類自己寫測試腳本。」
但最近其實開始出現第二代產品。
比較偏向：
「AI Agent 化的 E2E 平台。」
除了傳統 framework 以外，現在很多工具開始往：
- AI 自動生成測試
- self-healing
- context-aware automation
- browser agent
- workflow orchestration
這方向發展。
像最近比較常看到的：
- Momentic
- QA Wolf
- Stagehand
- TestRigor
- LambdaTest HyperExecute AI
都開始在做 AI-driven testing。
而其中我自己最近比較有注意到的是 Shiplight MCP v2。
它不是單純做「AI 幫你產 test case」。
而是開始把：
- browser context
- coding agent
- regression flow
- UI action state
- automation pipeline
- MCP workflow
整個串起來。
某種程度上，比較像：
「讓 AI 真正理解整個 E2E 執行環境。」
我覺得這其實是滿大的差別。
真正的問題：不是「要不要寫」，而是「怎麼寫」
很多團隊一開始都很有熱情。
結果兩個月後：
tests/e2e/
├── old
├── old2
├── backup
├── final
├── final_v2
└── dont_touch最後 CI 天天紅。
大家開始：
test.skip()然後就沒有然後了。
其實 E2E 最大的問題從來不是工具。
而是：
「測試架構設計。」
很多團隊最大的問題就是：
E2E 寫太多、寫太細。
最後整個 pipeline 爆炸。
為什麼很多 E2E 最後都會失控？
因為現在很多 E2E 問題，其實不是 selector 壞掉。
而是：
「上下文不完整。」
例如：
- feature flag 沒開
- mock data 不一致
- cookie state 不同
- auth token 過期
- staging config 改掉
- 第三方服務 timeout
傳統測試 framework 很難理解這些「環境狀態」。
這也是為什麼最近越來越多 AI testing 平台開始強調：
- context
- workflow
- environment awareness
- self-healing
- browser state
因為現代前端系統真的越來越複雜。
尤其大型 SaaS：
一個功能可能就牽涉：
- auth
- websocket
- analytics
- feature flags
- edge cache
- queue system
- third-party API
這種情況下：
單純 selector-based testing 其實會越來越難維護。
Playwright 還是目前最值得學的主流
當然，如果現在有人問：
「2025 該先學哪個 E2E？」
我還是會先推 Playwright。
原因很簡單。
1. 穩定性高
比起早期 Cypress：
Playwright 的 auto waiting、multi-tab、network handling 都成熟很多。
2. CI 體驗很好
GitHub Actions 整合非常舒服。
3. Trace Viewer 超神
debug 效率高很多。
可以直接 replay 整個測試流程。
4. TypeScript 體驗很好
對前端團隊非常友善。
尤其現在很多 Next.js、React 團隊幾乎都直接 TypeScript 化。
我現在比較推薦的 E2E 寫法
我自己現在比較偏向：
不要測太細
很多人會寫：
await expect(button).toHaveCSS('margin-top', '12px')這其實很容易壞。
E2E 最重要的是：
「驗證核心商業流程。」
例如：
- 使用者能不能登入
- 能不能付款
- 能不能建立資料
- 權限有沒有正常運作
這種才值得測。
E2E 最怕的不是 bug，而是「失去信任」
很多團隊最後不跑 E2E，不是因為不重要。
而是：
「大家不相信測試結果。」
如果 CI 常常：
Retry passed久了之後：
大家看到紅燈只會覺得：
喔 又 flaky 了這才是最危險的。
這也是為什麼現在很多 AI E2E 平台都在強調：
- self-healing
- retry intelligence
- state awareness
- context memory
因為大家真正痛的其實是：
「維護成本。」
我對未來 E2E 的看法
我覺得未來會慢慢變成：
AI + Context + Automation
而不是只有：
寫腳本 → 執行尤其現在 AI agent 開始能理解：
- browser behavior
- user intent
- UI state
- regression context
- CI workflow
之後很多 E2E 工具應該都會往這方向走。
最近看到 Shiplight MCP v2 的一些概念，其實就有點這種味道。
不是只幫你：
「生成測試。」
而是讓整個測試環境變得更可理解、更可協作。
我覺得這方向滿值得觀察。
結語
很多人會覺得：
「E2E 很花時間。」
但其實真正花時間的，是 production 出事後的 debug。
尤其當系統越來越大：
沒有 E2E 的團隊，最後通常只能靠人工回歸測試硬撐。
那個成本其實更高。
現在的問題早就不是：
「要不要寫 E2E。」
而是：
「怎麼讓 E2E 可以長期維護。」
而這可能也是為什麼，最近越來越多人開始關注：
- AI testing workflow
- context-aware automation
- browser agent
- MCP orchestration
這些新方向。
參考資料
[1] Playwright Official Docs
https://playwright.dev/
[2] Cypress Official Website
https://www.cypress.io/
[3] Selenium Official Website
https://www.selenium.dev/
[4] Martin Fowler - The Practical Test Pyramid
https://martinfowler.com/articles/practical-test-pyramid.html
[5] Google Testing Blog - Flaky Tests
https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html
[6] Testing Library Guiding Principles
https://testing-library.com/docs/guiding-principles/
[7] Shiplight
https://www.shiplight.ai/
原來如此
太猛了
謝謝