【ITニュース解説】A Check With a Zero Denominator Reports Clean

ソフトウェア開発では、コード品質のために自動テスト、静的解析（リンター）、コードカバレッジ計測などが利用される。これらは通常、CI/CDパイプラインという自動化プロセスの一部だ。しかし、これらのプロセスが「成功」と報告されても、実質的に何も実行されていない見かけ上の成功状態が発生することがある。例えば、テストが一つも実行されずにすべてスキップされたり、リンターが検査対象ファイルを一つも見つけられなかったり、コードカバレッジの計測対象コードが一つもなかったりするケースだ。このような状況でも、多くのツールは終了コードを「0」（成功）として返し、CI/CDパイプラインはそれを「成功」と判断してしまう。これは、見せかけの安全を報告し、問題の見落としにつながるリスクがある。

このような見かけ上の成功を防ぎ、実際に何かしらの作業が実行された場合にのみ成功と判断させるツールが「zerocase」である。zerocaseは、自動テストツールやリンターなどのコマンドをラップして実行し、その結果生成される機械可読なレポートファイル（JUnit XML形式のテストレポート、LCOV形式のカバレッジレポートなど）を解析する。そして、レポートに記載された情報から「合計数」と「実際に実行された数」の二つの数値を抽出する。zerocaseは、この「実際に実行された数」が事前に設定された最小値（デフォルトは1）を下回る場合、その実行全体を失敗と判断し、終了コードを非ゼロにする。これにより、たとえレポート上で「合計50テスト、スキップ50テスト」と書かれていても、実際に実行されたテストが0であれば、パイプラインは失敗として停止し、開発者は惑わされない。

zerocaseは、「実際に実行された数」という概念を非常に厳密に扱う。例えば、JUnit XMLレポートで合計テスト数50、スキップされたテスト50と報告された場合でも、zerocaseは実際に実行されたテストが0であると判断し、成功とはみなさない。 さらに、一つのテストケースがスキップと失敗の両方を報告するような特殊な状況も考慮される。zerocaseは、このようなテストケースは「実行されていない」と判断するため、それを失敗としてカウントすることはない。これは、全テストがスキップされたスイートが、見かけ上「全て失敗した」と誤解されるのを防ぐ重要な設計である。テストレポートが示す「失敗数」は単なる情報として参照されるが、実行全体の成否判断は、最終的に「実際に実行された数」とコマンドの終了コードに基づいて行われる。たとえレポート上の全てのテストが失敗と表示されても、実際にテストが実行されていればzerocaseのチェックは通過する。「実行された」と「成功した」という結果を明確に区別する。

zerocaseは、レポートの信頼性を確保するためにいくつかの重要なチェックを行う。一つ目は、レポートファイルが破損しているなどして解析できない場合だ。このような不正なレポートをゼロとして扱ったり、誤って成功と判断したりするのではなく、明確にエラーとして処理し、実行を失敗させる。これは、ツール自身が問題を隠すことを防ぐ。 二つ目は、レポートの鮮度、つまり現在実行されたコマンドによって生成されたものであるかを検証する。過去の実行で生成された古いレポートが誤って使用され、現在の実行が成功したかのように見せかけるリスクを防ぐためだ。過去のレポートの使用を許可するオプション（--allow-stale）も存在するが、その使用は強く推奨されない。 三つ目は、レポート内に記載されているテスト数の整合性チェックである。例えば、レポートのヘッダーに「テスト数47」と記述されていても、実際にボディに存在するテストケースの要素が47個未満であったり、それ以上であったりする場合がある。これは、テスト実行中にツールが途中で終了し、ヘッダーと実体が一致しないレポートが生成される場合に起こりうる。zerocaseは、このような不一致を発見した場合、ヘッダーの主張ではなく、実際にカウントされた要素数を信頼し、差異を報告する。これらのチェックにより、zerocaseはレポートの正確性と信頼性を確認し、見せかけの成功を防ぐ。

zerocaseの開発プロセスでは、品質と堅牢性を高めるために「ミューテーションテスト」という手法が用いられた。これは、コードにごくわずかな変更（ミューテーション）を意図的に加え、その変更が既存のテストによって検出されるかを確認する手法である。開発中に13個のミューテーションが適用され、うち2つは最初のテスト実行では検出されなかった。これらはテスト不足や想定外のシナリオを明らかにし、テストスイートの強化につながった。例えば、空ファイル対象のリンター実行や、スキップと失敗を両方含むテストケースといった、実環境で発生しうる未カバーの状況が発見され、テストが追加された。 また、開発者は既存の関連ツールについても徹底的な調査を行った。JUnitレポートを処理するツールやテスト数をカウントするツールは多数存在するが、zerocaseが解決しようとしている「実行結果レポートにおいて、実際に何も実行されていない状態を失敗とみなす」という特定の目的を果たすツールは見当たらなかった。この事前調査により、zerocaseが提供する機能が独自の価値を持つものであることが確認された。

zerocaseは強力なツールであるが、いくつかの正直な限界も存在する。レポート解析部分においては、完全なXMLパーサーではなく、より高速な簡易スキャナーを使用するため、コメントやCDATAなどが除去される。このため、意図的に複雑な構造や悪意のある内容を持つドキュメントに対しては、完全に防御しきれない可能性が残る。また、このツールは「実際にコードが実行されたか」という事実をレポート内容から判断する。これは、終了コードだけで判断するよりもはるかに信頼性が高いが、「実際に実行された」ことと「ただレポートがそのように報告している」ことの究極的な違いまでは判別できない。レポートを意図的に偽装することは不可能ではないが、偶発的な偽装は大幅に防げる。 総じて、zerocaseはCI/CDパイプラインにおいて、見せかけの成功を排除し、意味のあるコード実行があった場合にのみ次のステップに進めるようにすることで、開発プロセスの信頼性と品質を向上させる有効なツールである。