ミューテーションテストの開発組み込みを考える

前回の記事でJavaのミューテーションテストツールPIT(PiTest)を紹介しました^[1]。ミューテーションテストはテストの質を評価するうえで有望な技術ですし、PITを利用すれば特に設定を作り込むことなく簡便なテストの評価ができます。
しかし、機械的に変異を組み込むアプローチであるがために、日々の開発で利用するならば検討したほうが良い点もあります。引き続き以前の記事で利用してきた「よくあるサンプルアプリ」を題材にして、どのような理想が望ましいかを検討してみます。

この記事のコードサンプルは、Gitlab リポジトリ にありますので、興味がある方はあわせてご利用下さい。

リリース前にテストの十分性を評価するために「よくあるサンプルアプリ」に対してPiTestを利用してミューテーションテスト(解析)を行い、不十分だったテストを補強することができました。リリース前にテスト不備を検出できたのは良いこととして、最後にテスト不十分でバタバタするのは心臓によろしくありません。日々の開発の中でテスト不足があれば検出し、安心してリリースに臨みたいところです。
実のところ、PiTestの実行には数十秒の時間がかかっていました。実行されるテスト数も少ない開発の初期段階でこの所要時間とするならばこのまま使い続けるのは危険^[2]です。そこでPiTestの設定を見直して、日々の開発で無理なく利用できるかを検討することにしました。

前回の記事でも紹介しましたが、ミューテーションテストはテスト対象を機械的に改変してテストを実行するアプローチです。つまり、単純に考えるならば^[3]「改変を入れられる箇所」、「加える変異内容」、「(もとの)テストの実行時間」が乗数的に作用したものが合計の実行時間になります。

実行時のログを見ても(改変を行う準備である)カバレッジや依存関係の解析「coverage and dependency analysis」と、各ミューテーションに対するテスト実行・結果の解析「run mutation analysis」が処理時間のほとんどを占めています。つまり、改変対象コード、改変のパターン、実行されるテストコードのそれぞれを無駄のないように調整し、必要十分なミューテーション解析を行う設定ができれば所要時間を短縮できる可能性があります。

PiTestはテスト対象をコンパイルしたバイトコードに対して一定の改変を行う「ミューテーター」を作用させることでテスト対象の振舞いを変更し、変更後の「改変された振舞い」がテストの失敗という形で検出されるかを評価します。つまり、変更がないソースコード(プロダクトコード/テストコード)に対して再度実行した場合には同じ結果が得られると想定^[4]されます。

つまり、ミューテーションテストは「前回のミューテーションテスト結果」から変更があったソースコードのみを対象に実行できれば効率よくフィードバックを得られる技術と言えます。そのような利用に対しPiTestにはインクリメンタル解析や、対象を指定した解析実施の機能提供があります。

執筆時点で試験的(experimental)ではありますが、PiTestにはインクリメンタル解析というコードの変化点(増分)に対してミューテーションテストを実施する機能の提供があります。
インクリメンタル解析は、ミューテーションテストの実行時に対象ソースコード(プロダクトコード/テストコード)の情報を保存します。次回の実行時にこの情報を入力とすることで、「前回実行時からの変更」が無いものについては結果が変わらないものと推定し、解析の対象から除外します。

インクリメンタル解析を利用する場合、以下のようにPiTestの実行情報の入力元(historyInputLocation)と出力先(historyOutputLocation)を指定します。前回実行時との差分を対象にミューテーションテストを実施する場合は「出力先」に出力されている前回結果を今回の「入力元」とすれば良いため、両者に同じパスを設定すれば良いです。「複数のブランチを切り替えながら開発している」ような特殊事情がある場合は「出力先」にある結果が求めている前回結果とは異なる可能性があるため、都度設定を切り替えるなどの工夫が必要かもしれません。
より簡単な設定として「一時ディレクトリ」をhistoryの入力元/出力先とする設定(withHistory)も設定が可能です。ただしGradleプラグインの場合はビルドディレクトリが一時ディレクトリとして設定されているようなので、この設定の場合cleanタスクの実行時にhistoryも初期化されることに注意が必要です。

pitest {
    ・・・
    // ミューテーションテストの履歴データの入力元/出力先を設定
    historyInputLocation = ".mutation/history"
    historyOutputLocation = ".mutation/history"
    // よりシンプルに一時ディレクトリを履歴保存先とする設定も可能。この設定時にはInputLocationなどの設定は無視される
    // withHistory = true
}

例えば前回記事でのミューテーションカバレッジ改善前の状態を履歴として保持している状況で、テストコードを改善してpitestタスクを実行すると、履歴から変更があったテストコード(GreetServiceTest)を検出してGreetServiceのみを対象としたミューテーションテストが実施されます。

実行ログを見るとインクリメンタル解析によってミューテーションが削減(Incremental analysis reduced number of mutations by 3)されています。準備段階である依存関係の解析処理時間は伸びているものの、テストの実行時間も半分程度まで削減され、合計の実行時間は短縮できました。

インクリメンタル解析を利用すれば対象を絞ったミューテーションテストを簡便に実現できます。しかし、「前回実行時」との差分に対する動作にあたるため、例えば「マージ前にブランチ間で差分があるコードを対象にミューテーションテストを実施したい」ようなケースでは運用に工夫が必要になります。
「ブランチの分岐前のミューテーションテスト結果を保持しておいてマージ前に利用する」ような手段も採れるのですが、「マージ前」のようなケースではGitなどのソース管理ツールが管理している差分情報も活用できます。

PiTestでは以下のようにして変異対象とするクラスやテストクラスを設定可能です。テストクラスを指定するtargetTestsが未指定の場合にはテストクラスの設定としてtargetClassesと同じ値が使用されますので、改変対象を具体的なクラス名で指定する場合には注意が必要です。

pitest {
    ・・・
    // 変異対象クラス、実行対象テストクラスを配列で指定。ワイルドカードも使用可能
    targetClasses = [ "com.example.iwaki.service.GreetService","com.example.iwaki.BackApplication" ]
    // 実行対象テストクラスを指定しないとtargetClassesと同じ値が設定されるため、明示的にテストクラスを指定することが推奨される
    targetTests = [ "com.example.iwaki.service.*","com.example.iwaki.*" ]
}

この設定にSCMの管理情報から抽出した変更の情報などを反映することで対象クラスを指定可能です。ビルドの度にbuild.gradleを変更するのは煩雑ですので、実行時オプションや環境変数などで変更できるようにしておくと便利でしょう。例えばGradleのプロパティを介して(デフォルトの)対象を指定しておき、実行時オプション(-P)や環境変数(GRADLE_PROJEXT_XXX)で設定を切り替える^[5]ようにできます。

- gradle.properties
 // デフォルト設定をgradleのプロジェクトプロパティなどで定義することで実行時オプションなどで外部から変更可能に
 PITEST_TARGET_CLASSES="com.example.iwaki.*"
 PITEST_TEST_CLASSES="com.example.iwaki.*"

- build.gradle
----
 pitest {
    ・・・
    // gradle.propertiesの設定値を配列に変換して設定
    targetClasses = [ PITEST_TARGET_CLASSES ]
    targetTests = [ PITEST_TEST_CLASSES ]
 }

変更されたクラスを対象として指定すればインクリメンタル解析と同様にテストの実行時間が短縮できます。同一ブランチで開発を進めている時にはインクリメンタル解析/マージ前に変更内容を確認するときはSCMの情報を取り込み のように用途に応じて使い分けると便利です。

前回結果から変更があったコードに限定してミューテーションテストを実施することで処理を最適化できる可能性については別途記載しました。それ以外に、例えば結合テストやe2eテストコードのように実行時間が長いテストコードなどをミューテーションテストの対象から除外しても所要時間の短縮が狙えます。
「よくあるサンプルアプリ」ではPactを用いたContract Testの所要時間が長いものとなっています。このテストはConsumer側たるフロントエンドからの呼出しに対する応答の組み合わせ(Contract)を検証するものであり、サービス間の結合可能性を評価するためのテストです。他サービスとの結合を(実際に結合する前に)評価するテストですので、変異を入れて十分性を評価する意味が薄い^[6]ものでした。

ミューテーションテストの対象を指定するのと同様に、以下のように除外するクラスやテストクラスを指定できます。

pitest {
    ・・・
    // 変異対象外とするクラス、テストクラスを配列で指定。ワイルドカードも使用可能
    excludedClasses = [ "com.example.iwaki.BackApplication","com.example.iwaki.ClockConfig" ]
    excludedTestClasses = [ "com.example.iwaki.controller.GreetContractTest" ]
}

テストの処理時間が長いContract Testや、Configなどミューテーションテスト対象とする意味が薄いクラスを実行対象から除外することにより実行時間の改善が確認できました。

本稿ではクラス単位で対象/除外を設定する例を紹介しましたが、メソッド単位(excludedMethods/includedTestMethods)やテスティングフレームワークのグループ単位(includedGroups/excludedGroup)での設定も可能です。

テスト対象に対する変異の埋め込みは、執筆時点では公式ドキュメントを参照すると初期状態で下表に示す11種が有効化されています。また、変異を加えるロジックであるミューテーターは下表以外の18種もあわせて提供されており、個別のミューテーター名またはツールが提供するグループ名を指定して利用するミューテーターの変更が可能です。

※:変異内容に基づき筆者が推定

テスト対象の変異はミューテーターの作用によるため、利用するミューテーターの数と加えられる変異の数にはある程度の相関が想定されます。採用する開発技法やフレームワークなどにより発生し難いテスト漏れのパターン^[7]などに対しては、ミューテーターを絞り込むことで実行時間が短縮できるかもしれません。

今回はデフォルト設定されている各ミューテーターを外しても良さそうな根拠が希薄ですので、逆にミューテーターの数を増やしたら所要時間が伸びることを確認するのにとどめます。

pitest {
    ・・・
    // 利用するミューテーター名、またはツール側でまとめられたグループ名を指定
    mutators = [ "ALL" ]
}

以前に紹介したミューテーションテストツールPiTestについて、利用の障害となりうる「実行時間」を短縮するための設定について紹介しました。通常のテストに比べて時間がかかること自体は避けられないのですが、解析対象を適切に設定すれば現実的に利用可能なものになってくるのではないでしょうか。