【要約】mutmut導入で踏んだ2つのエラーと、性質テスト3本が手書き9本と同点になった実測 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
筆者が、コーディングエージェントが生成したテストの検証強度を確かめるために、価格計算モジュールを対象として調査を行った。その過程で、以下の技術的課題が浮き彫りになった。
- ・カバレッジ100%でも、ミューテーションスコアが77.8%に留まる問題。
- ・丸めモードの変更など、実害のあるロジックの欠落を検出できないテストの存在。
- ・mutmut 3系の導入時に、src/レイアウトやディレクトリ構成に起因するインポートエラーが発生する問題。
// Approach
筆者は、生存したミュータントを効率的に潰すため、手書きの境界値テストとHypothesisを用いた性質テストの比較検証を行った。
- ・生存ミュータントを対象に、境界値を明示する手書きテストを9本追加した。
- ・Hypothesisを用い、入力値を自動生成する性質テストを導入した。
- ・期待値の計算に実装を再利用せず、数学的定義から直接算出する「独立オラクル」を構築した。
// Result
テストの検証強度を向上させる手法として、性質テストの有効性が実証された。
- ・手書き9本（計21本）と、独立オラクルを用いた性質テスト3本（計15本）で、共にスコア87.0%に到達した。
- ・性質テストは、オラクルの独立性を確保すれば、少ないテスト本数で高い検証強度を実現できることが判明した。
- ・丸めモードの検証漏れという、実害のあるバグを検出することに成功した。
Senior Engineer Insight
> カバレッジは「実行されたこと」の指標であり、「検証したこと」の指標ではない。ミューテーションテストは、テストの「質」を定量化する極めて強力な手段だ。ただし、計算コストが課題となる。実戦では全件実施ではなく、重要モジュールやPRの差分に限定すべきだ。また、例外メッセージ等のノイズを追わず、丸めモードのような実害のあるバグに集中する審美眼が求められる。