測試報告沒人看？我用三層架構重構了它

周一早晨，咖啡在手。你打開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層只描述場景。報告終于能看了——因為每一層都在說人話。