規模型功能要有規模型測試

主張：如果一個功能存在的理由就是「撐得住 N」，那測試裡沒有接近 N 的案例，等於這個功能的核心宣稱從未被驗證過。

這次的形狀

一個宣稱支撐 100 萬列的功能，整個 diff 裡最大的 fixture 是 200 列（另外有 5001 列的 chunk 邊界測試、1000 列的 pipeline 測試）。所有 e2e 都把工作流引擎與物件儲存 mock 掉，驗的是 HTTP 契約而不是資料正確性；也沒有任何測試跑真實的 worker。

而真正的風險（記憶體峰值、單一大 transaction 阻塞 event loop、1 小時 timeout）全部只在大列數才出現。200 列的測試對它們一無所知。

為什麼會這樣，以及怎麼辦

大列數測試又慢又吃資源，跟單元測試放在一起會拖垮 CI——但這不是不測的理由，而是放錯地方的理由：

• 把規模測試獨立成一個不進 PR pipeline 的 job（nightly / 手動觸發）
• 至少要有一次真實環境的實測，並把數字（峰值記憶體、耗時、成功率）寫進 MR 或文件，否則所有容量宣稱都是估的
• 環境限制測不到的（瀏覽器記憶體、WASM、真實 worker），要明講靠手測，並記錄測了哪個裝置與瀏覽器
• 承認測試涵蓋度天花板，比假裝有涵蓋好

一個相關的反模式

測試裡的 fixture 若不是照實際產生路徑建的，就只驗證了撰寫者的假設 → 在共用 endpoint 加無條件檢查會打爛其他呼叫者 就是這樣漏掉的。