前言
前端 UI 一直是多變且複雜的題材，經歷各種工具迭代與起伏，像是：
- 早期瀏覽器標準混亂到穩定
- 沒有完善的測試工具到如今豐富的測試生態系
- CSS 管理方法論轉變（BEM、OOCSS…… -> Utility First）
- 早期 jQuery 指令式操作 DOM 轉向 React Vue 等現代聲明式組件框架
- Pre-styled 樣式庫（Chakra、AntD、Bootstrap） 到 Headless （zag、React Aria、Radix UI）框架盛行
經歷過太多的跌宕變化，這篇文章紀錄我認為現階段可以怎麼打造高效率可維護的前端。
坑點一：在不穩定的基礎上建立測試
打造自製的 UI 看似簡單，實際要處理的邊界情況（如瀏覽器差異、無障礙 a11y、鍵盤操作）極為複雜。
大多時候甚至不需要去製作已經爛大街的 UI ，很多界面看起來很簡單但實際維護起來卻是地獄，瀏覽器差異、版本問題、複雜的環境有太多的變因在網頁環境當中，舉例：Radix 一個看似簡單的 Dropdown Menu 就耗費數月上千個 commit 來完善。
建立測試需要花費代價，自動化測試應專注於產生價值的代碼：「業務邏輯是否行為正確且可被自動驗證？」
坑點二：速度與信心的兩難
網頁執行於瀏覽器環境中，自然要模擬瀏覽器進行測試，這也是傳統 E2E 測試方案如 Cypress 與 Playwright的強項，而另一方向是透過模擬瀏覽器環境與 API 如 jsdom 來達成在 Node.js 環境模擬測試網頁的目的。
- 模擬真實瀏覽器永遠太慢太貴。
- 模擬假的瀏覽器環境又存在許多與真實瀏覽器偏移的問題。
- 我無法表達光是一個輕微的 jsdom 模擬瀏覽器上的實踐差異就可能造成數小時的 Debug 有多惱人，很多奇怪的問題真的會需要參考成熟的大型專案如 Reka UI 的測試代碼才知道哪些變通方案是必須的。
這也是為什麼 Cypress Component Testing、Playwright Components 與 Vitest Browser Mode會出現，為了在現代網頁測試的「速度」與「信心」之間找到一個更優的平衡點，這些技術目前都還在實驗路上。了解測試目的與工具的差異並做出取捨。
坑點三：被遺忘的測試
很多專案寫了測試，但因為太慢、太不穩定（Flaky），導致：
- 錯誤的測試：一個不穩定測試對團隊信心的打擊，比沒有測試還嚴重。
- 測試只在被執行時才有價值：上一份工作的測試心得總結 為什麼要替軟體進行測試？
- 反饋速度： 讓測試能快速運行，開發者才願意在開發中頻繁執行它。