周一早晨,咖啡在手。你打開GitLab——CI紅了。經典場面。
點開報告,五屏長的文字墻。某處藏著:click操作超時。選擇器看起來沒問題——data-testid="checkout-submit"。但為什么失敗?數據庫掛了?前端沒渲染按鈕?還是某個API返回了意外響應?
![]()
想弄清楚?你得鉆進測試代碼逐行調試。在腦子里重構應用狀態。先讀五十行setup代碼,才能明白到底測了什么。
這才是爛測試報告的真實代價。不是失敗本身——而是你花一小時才能搞懂"什么失敗了、為什么失敗"。
多數團隊從這里開始。你寫了個干凈的Page Object:
代碼看著很棒。干凈、原子化,邏輯沒放錯地方。
但報告呢?長這樣:
? Test: User can complete purchase
- clickCheckout
- fillDetails
- submit
五秒內你能從這里面讀出上下文嗎?不能。開發者只能打開測試代碼,邊讀邊罵,在腦子里重構當時發生了什么。時間就這么沒了。
有人會說:"用test.step包一下不就行了?"
別。三個測試時確實好用。一百個測試時,項目就毀了。
復制粘貼會拖死你。login → cart → checkout這套鏈條最終會出現在大多數測試文件里。登錄邏輯變了?恭喜,手動改五十個文件。
維護變成噩夢。結賬流程現在需要"同意條款"復選框?去一百個地方插入await page.click(...)吧。
測試本身也失去了意義。十行的測試膨脹成五十行await test.step(...)噪音。真實的業務意圖被樣板代碼淹沒。
解決方案是在" dumb "頁面和測試之間加一個層。但多數團隊忽略了一個關鍵洞察:Flow不只是可復用的helper,它是一個業務實體。
想想電商應用。你有三個獨立的業務動作:
每個都值得擁有自己的Flow類。不是因為DRY(雖然這是附帶好處),而是因為每個都代表真實的業務概念,有自己的規則和職責。
然后你的Spec就像拼樂高一樣組裝它們:
// 場景1:完整主路徑
await cart.addProduct(laptop);
await checkout.placeOrder(address);
await payment.pay(card);
// 場景2:只驗證購物車行為
await cart.addProduct(laptop);
await cart.verifyTotal(1200);
這就是BDR(Behavior-Driven Living Requirements)的核心思想——我自己設計的Playwright測試架構方法,Cucumber-free的BDD替代方案,完整文檔在bdr-methodology.dev。
三層架構拆開了關注點:Page層處理選擇器,Flow層封裝業務動作,Spec層只描述場景。報告終于能看了——因為每一層都在說人話。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.