Dave Aronson氏はJSConf Hawaii 2020で、ミューテーション(mutation)テストを紹介した。ミューテーションテストの背景となる論拠、メリット、デメリットと落とし穴、その内部構造といった内容だ。
最初に氏は、ミューテーションテストがコードとともに、テスト対象のコードを変更する(ミューテートする)ことで、ユニットテストのマッチングについてもテストするものであることを説明した。通常の例題ベースのテストで保証されるのは、その例題の下でテストされた関数の動作が正しいことに限られている。従ってテスタは、一般的に無限であるテスト空間の適切なサンプルを使用することによって、このサンプルによる保証をより大きな空間に拡張できるようにしなければならない。テスト空間内のさまざまなテストに対して、確認されたテスト結果を有効ないし無効にする方法も考案しておく必要がある。
そのためにテスタは、２つの課題に突き当たることになる。それがTsing Yueh Chen教授の言う、信頼可能なテストセット(reliable test set)に関する問題とオラクル(oracle)問題である。
オラクル問題とは、与えられたテストケースのテスト結果の検証が極めて難しい、あるいは不可能であるような状況を示すものです。信頼可能なテストセットの問題とは、可能性のあるすべてのケースを実行することは通常不可能であるため、プログラムの正確性を判断可能なテストケースのサブセット(信頼可能なテストセット)を効率的に選択することが課題になる、という意味です。
ミューテーションテストはこの選択されたテストセット、すなわちテストコードの質に関する信頼性をテストするものだ。すべてのテストがパスする状況を出発点として、テストされるコードを修正し、テストスイートを繰り返す。テストスイートが信頼できるものであれば、テスト対象機能のエラーを含む実装をキャッチして、スイートの実行は失敗するはずだ。
Aronson氏が説明する。
[ミューテーションテストは]ユニットテストスイートのギャップを見つけることで、ユニットテストの厳密性を検証するものです。[...] 厳密性の欠如は、一般的にテストの不足や記述の不十分なテスト、メンテナンス不足のテストなどが原因で発生します。同時にそれは、コードが意味のあるものであることの確認にもなります。コードが意味を持っていれば、それを変更することによって、動作に明確な変化が生まれるはずだからです。
Aronson氏は次に、デメリットについて説明した。最初に挙げられるのは、ミューテーションテストがCPU時間を多く必要とするため、セーブ毎にコードベースすべてに対して実行するのは現実的ではないという点だ — 軽減手段としてツールは通常、インクリメンタルモードを用意している。
Aronson氏はまた、ミューテーションテストは初心者向けのテクニックではない、とも主張している。テスト対象コードを変更してもテストがパスする場合は、慎重な解釈が必要だ。この場合、テストがパスするというのは、一般的には誤検知にあたる。すなわち、現在のテストセットの信頼性が十分でない(テストが欠落している)か、あるいはテスト自体の一部に誤りのある可能性があるのだ。
つまりミューテーションテストは、ソースコードに失敗を挿入することによって、エラーを含んだ機能実装を作り出そうという、失敗ベースのテクニックなのである。Aronson氏は例として、Netflixが使用するレジリエンスツールのChaos Monkeyを挙げた。このツールは、テストシステムに対してインスタンスエラーをランダムに発生させることで、システムの安定性をテストし、エラー回復上の問題点を洗い出そうというものだ。
ミューテーションテストツールは一般的に、関数と、それに対応するテストを見つけることで動作する。次に関数コードを分析して抽象構文木にする。ミューテーションはこの構文木レベルで適用され、変更した構文木から関数コードが逆生成される。条件式の境界が変更される場合もある("<"から"<="、"=="から"!="、"if(cond)"から"if(true)"のように)。インクリメント(++)をデクリメント(--)に変えることもある。一部のメソッドやコンストラクタ呼び出しを無効にする場合もある。
第2回のJSConf Hawaiiは2月にハワイで行われた。Web開発とJavaScriptに特化した、3日間の、単一トラックのカンファレンスだ。すべての講演はオンラインで公開されており、詳細な技術情報やイラストレーション、コードサンプルなどが含まれている。