AI生成テストを監査する：CIが「合格」でも、その半分は何の証明にもならない
テストに合格すると、それが証拠であるかのように感じられる。しかし、実際にはあなたが考えているほどのものではない。
テストとは、コードが期待通りに動作することを断言するものである。もし同じ作成者がコードと期待値の両方を書いた場合、その期待値はコードによって形作られてしまう。つまり、そのテストは「合格するように」書かれているため、合格するのである。
緑色のチェックマークは、テストがコードと一致していることを証明するに過ぎない。コードが正しいことを証明するものではない。
この問題は、AIエージェントがプルリクエスト全体を送信するようになると、さらに深刻化する。AIは実装とテストを一度に書き上げるからだ。作成者が変わったからといって、そのチェックマークの信頼性が高まるわけではない。
私はこのギャップを見つけるために mirror_audit.py を作成した。これはASTを使用してテストのソースを読み取る。コードを実行することは決してない。そして、以下の3つの一般的なパターンを探し出す。
- 再計算（The Recompute）：テストがコードと同じ数式を使用している。これは、仮装した
f(x) == f(x)に過ぎない。 - ゴールデン・リテラル（The Golden Literal）：テストが以前の実行結果からコピーした数値を使用している。これにより、バグを含め、初日にコードが何を出力したかにテストが固定されてしまう。
- スモークテスト（The Smoke Test）：結果が
Noneでないことは確認しているが、実質的なアサーションを欠いている。
私はこれを2つのテストスイートに対して実行した。
最初のスイートは、実装をそのまま反映するように設計されていた。そのミラー比率（mirror-ratio）は50.0%だった。CIは失敗した。テストの半分は、独立したシグナルを何も持っていなかった。
2番目のスイートは誠実なものだった。ネガティブケースと独立した期待値を使用していた。ミラー比率は0.0%だった。CIは合格した。
ミラー比率はバグの発生率を測定するものではない。欠落している「独立したシグナル」を測定するものだ。それは、あなたの「合格しているCI」のうち、どれほどが単にコードに同調しているだけのテストスイートであるかを教えてくれる。
もしテストが実装と同じ誤った結果を計算した場合、テストは緑色のままとなる。もしテストが真の契約（contract）を断言していれば、テストは赤くなり、バグを捕捉できる。
カバレッジだけを見るのはやめよう。自分のテストが、本当の理由によって実際に失敗し得るものかどうかを問い直すべきだ。
Source: https://dev.to/alex_spinov/audit-ai-generated-tests-half-of-green-ci-proves-nothing-4bmb
Optional learning community: https://t.me/GyaanSetuAi