壓力測試 Story
問題：示範資料永遠是乖的
寫 story 時，示範資料是自己編的，於是：
- 名稱剛好三四個字
- 金額剛好五位數
- 選項剛好四個
- 清單剛好七筆
- 沒有一個是負數，也沒有一個是 0
元件在這種資料下當然沒問題。真實資料裡一定有一筆二十個字的名稱、一個十三位數的金額、 一個二十四個選項的多選、一批空清單。 這些不是罕見狀況，是上線第一週就會遇到的東西。
「示範資料下正常，真實資料下版面爆掉」是後台系統最常見的驗收退件原因， 而它完全可以在元件層就攔下來。
做法：一個獨立分類，用極端值撞
在 Storybook 開一個頂層分類（例如 壓力測試/），每一類極端值一支 story。
✅ 這樣做
壓力測試 story 獨立成一個分類。
🚫 不要這樣
不要混進元件的一般 story 裡。一般 story 是「這個元件該長什麼樣」，給人看的； 壓力測試是「它撐不撐得住」，給人撞的。兩者混在一起， 拿去給設計看的時候會被誤會成「這就是正常樣子」。
七類極端值
| 類別 | 測什麼 | 該看什麼 |
|---|---|---|
| 超長文字值 | 內容超出欄寬 | 截斷還是換行？截斷的話有沒有 Tooltip？換行的話同一列其他欄位有沒有跟著變高？ |
| 超長標籤 | 欄位／分頁／徽章的標籤過長 | 標籤換行 vs 元件變形。標籤可以換行，控制項不該變形 |
| 超大數值 | 13 位數金額、超長小數 | 千分位還在嗎？會不會自動縮小字級（不該）？容器是捲動還是撐破？ |
| 超多選項 | 多選 24 項、單選 6 個長標籤 | 換行後高度變化能否接受？換行的分段選擇是不是該改用下拉？ |
| 超多欄位 | 表格 10 欄以上 | 凍結首欄還有效嗎？水平捲動時黏性表頭有沒有透出後面的內容？ |
| 超多筆 | 42 筆（跨越分頁門檻）、200 筆 | 分頁器出現時機、合計是否算全部、捲動是否卡頓 |
| 多類別圖形 | 20 個類別、12 段的堆疊 | 標籤會不會糊成一團？超過色票數量怎麼處理？最窄的那段還點得到嗎？ |
每一類都要有兩個極端
不只測「很多」，也要測「沒有」：
| 很多 | 沒有 |
|---|---|
| 200 筆資料 | 0 筆資料 |
| 24 個選項 | 0 個選項 |
| 10 個變更 | 0 個變更 |
| 20 個類別 | 1 個類別、全部為 0 |
「沒有」那一側更容易出事，因為它常常是除以零、取 Math.max 於空陣列、
或是「整塊元件直接消失」——而消失的 UI 沒有人會在開發時注意到。
壓力測試會產出規範，不只是找 bug
這是它最容易被低估的價值。撞完之後你會被迫回答一些原本沒想過的問題， 而這些答案就是規範：
| 撞出來的問題 | 變成的規範 |
|---|---|
| 20 個字的徽章把表格行高撐開 | 徽章文字 2–6 字，寫不短就換元件 |
| 13 位數金額縮小字級後同列有兩種字級 | 數值欄一律不縮字級，改為容器捲動 |
| 6 個長標籤的分段選擇換行了 | 分段選擇換行即失去意義，該改下拉 |
| 20 個類別的圖形標籤糊成一片 | 超過上限彙總成「其他（N 項）」，不要循環用色 |
| 24 筆變更把送出鈕推出畫面 | 清單限高、內部捲動、總數置頂 |
上面這幾條規範，全部是這個 repo 的元件文件裡實際存在的內容——它們都是撞出來的， 不是設計時想出來的。
✅ 這樣做
每次撞出問題，先問「這是要修元件，還是要寫一條規範？」
🚫 不要這樣
不要每次都選修元件。「讓元件在任何輸入下都好看」是做不到的目標， 而且會把元件撐成一個充滿特例的怪物。有些極端值的正確答案是「不要那樣用」—— 那就寫進文件的〈何時不要用〉。
什麼時候跑
| 時機 | 做什麼 |
|---|---|
| 新增元件時 | 至少補一支「最長／最多」與一支「空」 |
| 改版面相關的樣式時 | 把該元件的壓力測試全部看一遍（這是視覺回歸最便宜的替代品） |
| 驗收前 | 切深色模式 ＋ 灰階列印各看一次 |
壓力測試 story 不需要斷言、不需要自動化，它的產出是人眼看到的那一眼。
成本很低（多數是一行 Array.from 造資料），而它擋掉的是上線後才被使用者發現的那一類問題。