この記事は playpark Blog からの転載です。
この記事で分かること
- 「green→greenの比較」から論理的に言えることが「悪化していない」以上には何もない理由
- CIのpass/failだけを見る運用と、before/after記録を比較する運用の違い
- テストをskip・削除して見かけ上green化する「なりすまし修正」を機械的に見分ける視点
背景: こういう課題があった
バグ修正のPRを出し、CIが全部greenになったのを見て「直った」と判断してマージする。この流れ自体はどの現場でもやっていることだが、そのgreenが「修正前に同じテストが赤かったことを確認した上でのgreen」なのか、「修正後に一度実行しただけのgreen」なのかは、見た目では区別がつかない。CIやAIエージェントの自動修正ループのように実行が速く何度でも回せる環境ほど、この区別を省略しても表面上は困らないため、実は何も検証できていない修正がそのままマージされやすくなる。
選択肢の検討
バグ修正の検証をどう担保するか、いくつかの方法がある。
| アプローチ | メリット | デメリット |
|---|---|---|
| CIのgreen/redだけ見る | 追加コストなし | green→greenの区別がつかない、なりすまし修正も見逃す |
| PRの説明文に「修正前は落ちていた」と手動記載 | ツール不要 | 書き手の自己申告に依存し機械的に担保できない |
| fix前にredを記録し、before/afterを比較する(採用) | 機械的に検証可能、テスト削除も検出できる | 一手間かかる、CI設計に組み込みが必要 |
なぜこのアプローチを選んだか
バグ修正の前後でテストを実行した結果は、次の4パターンに分類できる。
| 修正前 | 修正後 | 呼び名 | 言えること |
|---|---|---|---|
| red | green | improved | そのテストが検知していた不具合が直った、と主張できる |
| green | green | unchanged | 何も言えない。元から通っていたのか、たまたま通ったのか区別できない |
| red | red | 未解決 | まだ直っていない |
| green | red | regressed | 悪化した |
問題はgreen→greenの行だ。修正前を見ずに修正後だけgreenを確認しても、これがimprovedなのかunchangedなのか判定しようがない。全部green→全部greenの比較からは、原理的に「改善した」という判定は出てこない。出せるのは「少なくとも悪化はしていない」までで、それは「直った証拠」とは別物だ。この区別を機械的に担保するには、修正前の失敗状態を記録しておく以外に方法がない。
実装例
素のvitest(jestでも同様)であれば、次の3ステップで再現できる。
# 1. 修正前: 失敗状態を記録する
npx vitest run --reporter=json --outputFile=before.json
# 2. ここでバグを直す
# 3. 修正後: 結果を再度記録する
npx vitest run --reporter=json --outputFile=after.json
before.jsonとafter.jsonを突き合わせ、どのテストIDが失敗から成功に変わったか(あるいは変わっていないか)を確認する。見るべきポイントは「テストの本数が減っていないか」「減っていたら理由は何か」の2点だけでいい。テストを通すことだけを目標にすると、バグを直す代わりにテストの方をskipやdeleteして帳尻を合わせる経路が紛れ込みやすいため、この確認を省略しないことが重要になる。
まとめ: どういう場面で使うべきか
CIやAIエージェントの自動修正ループのように、テストのpass/failを自動判定に使っている場面では、「greenになったか」ではなく「同じテストがfail→passに転じたか」を確認する運用にしたほうがいい。修正前の失敗を記録していなければ、全緑→全緑の比較からは何も証明できない、という前提を機械的なルールにしておくだけで、静かなテスト削除によるなりすまし修正をかなりの割合で防げるようになる。
さらに深掘りしたい方へ
この記事では「fix前にredを記録する」検証パターンの考え方を解説しました。
テストが全部greenになっても、バグが直った証拠にはならない ではさらに：
- 自社製OSSツール(vdelta)によるbefore/after記録の自動化と、git pushフックへの組み込み方
- CLAUDE.mdに明文化した運用ルールの実例(
repaired: N same-surfaceなどの判定基準) - 依存バージョンを継続的に追従させているdogfooding運用の中身
を扱っています。
playpark について
playpark LLC - 業務自動化・AI活用・Web開発
