#なぜ今日これを選んだか

バグ修正のレビューで一番確認しづらいのが「このテスト、修正前は本当に落ちていたのか」という点だ。落ちないテストを足しても直った証明にはならないが、レビュワーは普通そこまで検証しない。この記事はその確認を人の善意ではなくCIの履歴に肩代わりさせる。小さいが効き目のある発想の転換だった。

#要点

• Vitest の test.fails を使うと「落ちることを期待するテスト」をCIの結果として記録できる
• バグ修正を2つのPRに分ける。PR 1 は再現テストだけ（仕様通りのアサーション＋ .fails 付き）、PR 2 で .fails を外して実装を直す
• 同じテストが Red → Green に変わった遷移がCI履歴に残り、「直った根拠」が後から追える
• 複数PRのスタック管理は gh stack で一括作成・マージができる

#自分にとっての示唆

これは外資の面接で聞かれる「どうやって品質を担保しているか」への具体的な回答になる。「テストを書いています」は誰でも言うが、「再現テストが落ちる状態をCIに残してからPRを分けています」と言えると、レビュー文化を設計できる人として見られる。React × Go を狙うなら、コードの量より運用の設計で差をつけたい。

明日からやるなら、次に踏むバグ1件で試すのがいい。全部の修正でPRを分けるのは重すぎるので、原因が非自明だったバグ限定でよい。PR 1 のタイトルに repro: と付けておけば、チームに説明しないまま試せる。日本語で説明しづらい概念ほど、英語のPR文化ではそのまま通じるという副産物もある。

原文を読む →