test(comments review): 驗證 Review comments 依嚴重度排序 #33
@@ -208,6 +208,10 @@ describe('postFindingsReview', () => {
|
|||||||
reviewCalls[0].comments.map(c => c.path),
|
reviewCalls[0].comments.map(c => c.path),
|
||||||
['app/a.js', 'app/b.js', 'app/c.js'],
|
['app/a.js', 'app/b.js', 'app/c.js'],
|
||||||
);
|
);
|
||||||
|
assert.deepEqual(
|
||||||
|
|
|||||||
|
reviewCalls[0].comments.map(c => c.body.match(/嚴重等級\*\*:(.+)/)?.[1]),
|
||||||
|
admin
commented
嚴重等級:🟡 警告 **嚴重等級**:🟡 警告
**審查員**:Leo
**問題**:測試中直接硬編碼了嚴重等級的顯示文字 `['🔴 嚴重', '🟡 警告', '🔵 建議']`。這些字串很可能是應用程式中定義的常數,直接複製貼上會導致未來當這些等級的顯示文字需要調整時,必須同時修改應用程式程式碼和測試程式碼,增加維護負擔,也容易造成不一致。
**建議**:如果這些嚴重等級的顯示文字在應用程式中已有定義(例如:`SEVERITY_LEVELS.CRITICAL.DISPLAY_TEXT`),建議在測試中引入並使用這些常數,確保測試與實際邏輯保持同步,避免重複定義的技術債。
|
|||||||
|
['🔴 嚴重', '🟡 警告', '🔵 建議'],
|
||||||
|
);
|
||||||
assert.deepEqual(
|
assert.deepEqual(
|
||||||
reviewCalls[0].comments.map(c => c.new_position),
|
reviewCalls[0].comments.map(c => c.new_position),
|
||||||
[10, 20, 30],
|
[10, 20, 30],
|
||||||
|
|||||||
Reference in New Issue
Block a user
嚴重等級:🟡 警告
審查員:Bard
問題:程式碼中直接嵌入了正規表達式
/嚴重等級\*\*:(.+)/,這是一個「魔術值」。它讓程式碼的意圖不夠清晰,且若未來需要修改此模式,會增加維護的困難度,也使得該行程式碼過於冗長,影響閱讀流暢性。建議:建議將此正規表達式提取為一個具名常數,以提升可讀性與可維護性。例如:
嚴重等級:🟡 警告
審查員:Leo
問題:測試中用來解析
c.body的正規表達式(/嚴重等級\*\*:(.+)/)過於依賴特定的字串格式「嚴重等級**:」。如果未來這個前綴文字有任何微小的變動(例如:多一個空格、換個標點符號、或改用其他詞彙),即使語義不變,測試也會立刻失效,導致不必要的維護工作,增加了測試的脆弱性。建議:考慮讓正規表達式更具彈性,例如使用
\s*匹配空白,或將這個字串格式的解析邏輯封裝成一個輔助函式,並在該函式中處理可能存在的格式變動彈性。如果c.body的內容是從結構化資料組裝而來,更理想的做法是測試該結構化資料本身,而非其最終的字串呈現。嚴重等級:🟡 警告
審查員:Mage
問題:此處的正規表達式
嚴重等級\*\*:(.+)使用了貪婪匹配.+。這可能導致它捕獲到「嚴重等級**:」後方,直到字串結尾的所有內容,而非僅僅是預期的嚴重等級文字。若c.body中在嚴重等級後方還有其他文字(例如:「嚴重等級**:🔴 嚴重。請注意此問題。」),此測試將會因為提取到錯誤的內容而失敗,或在實際情況與預期不符時,無法正確驗證。建議:為了確保只捕獲到預期的嚴重等級文字,應使用更精確的正規表達式。考量到測試的預期值是固定的
['🔴 嚴重', '🟡 警告', '🔵 建議'],最穩健的作法是直接匹配這些值,例如:c.body.match(/嚴重等級\*\*:(🔴 嚴重|🟡 警告|🔵 建議)/)?.[1]或者,如果嚴重等級後方可能跟隨其他文字但有明確分隔符(如句點、換行符或字串結尾),可以使用非貪婪匹配並指定邊界,例如:
c.body.match(/嚴重等級\*\*:(.+?)(?:\s|$|\.|\n)/)?.[1]嚴重等級:🟡 警告
審查員:Maya
問題:這個新增的斷言只驗證了評論內文(
c.body)中存在且格式正確的嚴重等級資訊。然而,它沒有涵蓋到評論內文可能沒有嚴重等級資訊,或是嚴重等級格式不符預期的情境,這讓程式碼的行為在這些邊界條件下缺乏驗證。建議:建議新增測試案例,或擴充現有案例的測試資料,以涵蓋以下情境:
undefined或預設值)。undefined或拋出錯誤)。