AIが人間よりも空疎なテストを書くかどうかを測定した——そんなことはない

ソフトウェア開発において、自動テスト、型チェック、継続的インテグレーション（CI）ゲートは、コード品質を保つための重要な防衛線とみなされています。しかし、これらの防御線そのものに欠陥がある可能性があります——それらは存在し正常に動作しているように見えながら、実際には何も検証していないことがあります。このような「空疎」なガードは、まったくガードがないよりも危険です。なぜなら、偽りの安心感を与えるからです。最近、ある開発者が1つのリポジトリを分析したところ、7つの空疎ガードを発見し、その結果、このような問題を検出するための新しいオープンソースツールvoidguardを開発しました。

voidguardは4種類の空疎ガードを識別できます。1つ目は「決して実行されないテスト」で、環境フラグやCI構成によってスキップされるが、実際にはどこでも実行されていないものです。2つ目は「何もチェックしない型ゲート」で、mypyやtsconfigの設定ミスにより、型チェックを実行していると主張しながら実際には有効なコードをチェックしていないものです。3つ目は「静かに破棄される設定」で、Pythonスクリプトで設定されたPYTHON*変数がコマンドライン引数によって上書きされたり、Dockerビルドで定義されたARGが誤った場所で使用されたりするケースです。4つ目は「決して発動しないCI条件」で、ワークフローのトリガー条件が決して発生しないイベントを参照していたり、スケジュールされたジョブが一度も正常実行されなかったりするものです。検出された空疎ごとに、voidguardはVOID（空疎）、WARN（警告）、またはUNKNOWN（不明）の明確な判定を下し、詳細な検索範囲情報を提供します。

ただし、voidguardは万能ではありません。作者は、このツールが捕捉できない3種類の空疎を明示しています。1つ目は「意味的空疎」で、例えばフィールドの型がnull許容と宣言されているが実際には値が代入されない、または関数がnullを返すが呼び出し側がそれを有効値として扱う場合などです。これらはファイル構造分析ではなく、型フローやデータフロー分析を必要とします。2つ目は「プロセス空疎」で、すべての自動チェックが緑色を示しているにもかかわらず、人間による承認ステップがマージプロセスで迂回されるケースです。このような人的判断の欠落をスキャンツールが捕捉することはできません。3つ目は「実行を必要とする空疎」で、voidguard自体はコードを実行しないため、実行時にのみ発覚するエラーは発見できません。静的解析で判断できない場合、voidguardは正直にUNKNOWNとその理由を返します。なぜなら、空疎を主張しながら誤検知を生み出すツール自体が空疎ガードだからです。

voidguardの誕生は具体的な事例に端を発します。あるリポジトリの一度のスイープで、著者は7つの空疎ガードを発見しました。統合当初から静かにスキップされていたコアの整合性テスト、何もチェックせずにパスしていた型ゲート、マージ操作によって迂回された承認ステップ——これらすべてのCIステータスは緑色でしたが、実際の検証効果はゼロでした。voidguardはこのスイープ手法を一般化したものです。このツールはPyPIで公開されており、ソースコードもGitHubで入手可能です。これは実用的な検出ツールであると同時に、自動テストと検証においては検証そのものの有効性を検証しなければならず、そうでなければ緑色のステータスは偽りの安心感しかもたらさないという重要なメッセージを伝えています。