From 0aee3459e645f6aa06321bf4920769975a4c0fb5 Mon Sep 17 00:00:00 2001 From: Jeffery Date: Tue, 23 Jun 2026 16:44:43 +0800 Subject: [PATCH] =?UTF-8?q?chore(ai-review=20=E7=8B=80=E6=85=8B):=20?= =?UTF-8?q?=E8=A7=A3=E6=B1=BA=E9=82=8A=E7=95=8C=E6=95=B8=E5=80=BC=20findin?= =?UTF-8?q?gs=E3=80=81=E6=8E=92=E9=99=A4=E5=94=AF=E8=AE=80=20fixture=20?= =?UTF-8?q?=E8=AA=A4=E5=A0=B1=EF=BC=8C=E6=B8=85=E7=A9=BA=20findings.json?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .gitea/ai-review/exclusions.json | 6 ++++++ .gitea/ai-review/findings.json | 35 +------------------------------- 2 files changed, 7 insertions(+), 34 deletions(-) diff --git a/.gitea/ai-review/exclusions.json b/.gitea/ai-review/exclusions.json index 0c8f679..382fa8a 100644 --- a/.gitea/ai-review/exclusions.json +++ b/.gitea/ai-review/exclusions.json @@ -524,5 +524,11 @@ "role": "Rogue", "original_finding": "在 recordRateLimit 中頻繁呼叫 lowerCaseKeys，對每個請求的 headers 複製與轉換，增加記憶體分配開銷；建議改用不分大小寫存取避免複製。", "reason": "過度設計／非熱路徑。recordRateLimit 每次 LLM 回應只呼叫一次（一輪審查約 13 次），headers 物件小，複製成本可忽略；改用不分大小寫存取器反而增加複雜度，效益不成比例。" + }, + { + "location": "app/usage.test.js:250", + "role": "Leo", + "original_finding": "測試案例直接引用 describe 外層定義的 `usage` 變數，若被其他測試修改會造成測試間隱性耦合；建議改用區域變數或工廠函式生成測試資料。", + "reason": "誤判。該 `const usage` 為不可變的測試夾具，所有測試只讀不寫、未曾被任何案例 mutate，不存在跨測試耦合；新增的邊界測試已各自使用區域 usage 物件。為一個唯讀 fixture 改工廠函式屬過度設計。" } ] diff --git a/.gitea/ai-review/findings.json b/.gitea/ai-review/findings.json index abcb0eb..fe51488 100644 --- a/.gitea/ai-review/findings.json +++ b/.gitea/ai-review/findings.json @@ -1,34 +1 @@ -[ - { - "level": "critical", - "role": "Mage", - "location": "app/usage.test.js:254", - "problem": "測試情境雖處理了 NaN，但未涵蓋 `limit` 為 0 或負數等極端數值（例如除以零導致的錯誤或異常百分比計算）。若 `formatUsageStatsLine` 內部有計算 `(used / limit) * 100` 或類似邏輯，傳入 0 會產生 `Infinity`，傳入負數則會產生荒謬的邏輯結果。", - "suggestion": "建議新增對 `limit: 0` 以及負數邊界值的測試案例，確保函式對這些非預期的數值輸入同樣能輸出「無法計算」或相應的錯誤處理訊息，而非輸出 `Infinity` 或負百分比。", - "is_new": true - }, - { - "level": "warning", - "role": "Leo", - "location": "app/usage.test.js:250", - "problem": "在測試案例中直接引用外部定義的 `usage` 變數，若該變數在其他測試中被意外修改，會導致測試間的隱性耦合，使得測試結果難以預測，降低測試的可維護性。", - "suggestion": "建議直接在測試函式內定義該案例所需的完整 `usage` 物件，或是使用工廠函式（Factory function）來生成所需的測試資料，確保測試案例的獨立性與確定性。", - "is_new": true - }, - { - "level": "warning", - "role": "Maya", - "location": "app/usage.test.js:250", - "problem": "目前的測試僅針對 NaN 的情況，但未考慮到 Infinity、null 或 undefined 等其他同樣可能導致格式錯誤或輸出異常的「無效數字」邊界條件。", - "suggestion": "建議補充針對 Infinity、null 與 undefined 的測試案例，確保這些值在 formatUsageStatsLine 中皆能正確處理並輸出友善的錯誤訊息，而非損壞的文字。", - "is_new": true - }, - { - "level": "info", - "role": "Maya", - "location": "app/usage.test.js:250", - "problem": "目前的測試案例將多個欄位同時設為 NaN，測試邏輯較為單一，未能明確驗證「單一欄位無效」與「組合欄位無效」時的具體行為差異。", - "suggestion": "建議將測試拆分為更細緻的案例，分別驗證 quota.limit 與 rate.limit 欄位在單獨無效，以及兩者同時無效的情況，以確保各欄位的防禦性邏輯皆有被完整覆蓋。", - "is_new": true - } -] +[]