用 Playwright 測行為，不只衝覆蓋率

概要

• 程式碼暴增，產能不一定跟著增Marlene 引用 GitHub 的數字，2025 年約有 10 億個 commit，2026 年每週約 2.75 億個，接著問的是，這些程式碼有沒有換來更高的產能。
• 乾淨的程式碼庫才放得大 AI 的好處Marlene 轉述一份 Stanford 研究，說乾淨的程式碼庫會放大 AI 帶來的增益，沒有把關的 AI 則會放大混亂。建議把測試覆蓋、型別覆蓋、文件和模組化當作重點。
• 單元測試和覆蓋率有盲點測試綁在實作細節上，改個名字就會壞；AI 又常寫出自我肯定的測試，覆蓋率全綠，系統行為卻沒被驗證。
• 改測行為，用 Playwright 驅動瀏覽器Playwright 模擬使用者操作，做端對端測試。Marlene 的做法是讓 agent 針對功能需求先寫會失敗的 Playwright 測試，再寫程式讓它通過。
• AI 讓紅、綠兩步變快，時間留給重構Marlene 認為 TDD 以前被嫌慢，有了 AI 之後前兩步很快，開發者該把最多時間花在檢視並改善 agent 寫出的程式碼。
• 現場示範與使用建議Marlene 用 GitHub Copilot CLI 加 Playwright MCP server 走完一輪，最後給了幾點實務建議，Q&A 也回答了狀態管理、行動版和非瀏覽器的問題。

原話

• “clean code bases amplify AI gains and AI productivity, while unchecked AI in a code base is going to amplify entropy.”

  乾淨的程式碼庫放大 AI 的增益，沒把關的 AI 則放大混亂；這是 Marlene 轉述那份 Stanford 研究的結論

  ▶ 02:48

• “AI sometimes generates self-affirming tests.”

  AI 有時會生出自我肯定的測試

  ▶ 07:52

• “that red part and the green part are fast.”

  紅燈和綠燈那兩段變快了

  ▶ 09:26

• “commit your code before you actually get it to fix the test.”

  在讓它修測試之前，先把程式碼 commit

  ▶ 16:35

延伸

• Marlene 用一段 Playwright 腳本說明測試長什麼樣子：先到玩具頁、找到搜尋框、填入 Furby，瀏覽器就會自動跑完搜尋。
• Marlene 說讓 agent 修測試前先 commit，是因為不 commit 的話，agent 可能記不得之前改過什麼。