テストカバレッジが100％でもそれが意味のあるテストかは断言できない　Mutation Testでテストコード自体の検証をしよう

カバレッジとは？

Kanon氏：「カバレッジとは？」という話なんですけど。テストコードがプロダクションのコードのうちのどれだけ網羅できているか、通しているかの尺度になってくるという感じです。

それ自体は、ちょっと（スライドは）読まないんですけど、分岐、行、ステートメント、関数という4つの大きな枠で説明されます。これは、復習レベルですね。

そのカバレッジを、どうやら50から80パーセントぐらいを目標とするのがよさそうなのではないか。というのが自分が言いたい話でして、10から40パーセントだと、さすがに低すぎるかなというところです。

逆に、90パーセント以上を目指そうとすると、今度は高すぎで、プロダクトのクリティカルな実装部分以上に、重箱の隅にまでがんばってテストを書こうとする時間が本当に必要かなというところは確認したい、というのが自分の意見になります。

じゃあ、その目標とするテストのカバレッジの割合を決めたら、今度は、その閾値に満たない場合は、CIを止めるような設定を入れてあげるのがいいんじゃないかなというところです。

最初は、目標値をそのままにすると、だいたい毎回CIがこけてなかなか大変なかたちになってくるので、全体のカバレッジのマイナス5パーセントぐらいあたりから始めていって、徐々にその閾値を上げていくことを目標にしていくといいのかなと思います。

これがその例のパターンで、カバレッジの閾値を85パーセントに設定した時はエラーにならずに、これは今89.4パーセントで取り切っているという状態で、それを90パーセントという閾値にすると、テストコードがこけるようになりましたというようなスライドでした。

定期的にカバレッジレポートを見る習慣を

今度は、閾値を設定した上でカバレッジレポートを精査しましょうよという話になってきます。さっき見ていたこのトータルの閾値が、「89.7パーセントか、あぁ、よしよし」というふうに見るのもいいんですけど。

そうした時にですね、例えばこれはちょっと極端な例なんですけど、この「BroadcastServiceProvider」というところの閾値を見ると、0パーセントになっています。

プロダクトの中で本当に大事なテストが、ここに書かれているんだったとしたら、いくら全体が89.7パーセント、「あぁ、よしよし、高いな」となったとしても、これは意味がないよねという話になってくるかなと思います。

なので、定期的にカバレッジレポートの中を見て、テストされていない領域はないか、本当にテストされるべきところがされているかどうかというところも目を配る必要があるかなというのが私の意見です。

それをするには、実際にカバレッジレポートを見るのがいいんですけど、それ自体が習慣にならないとなかなかやらない話になってきちゃうので。週に1回ぐらい「Slack」に通知したりだとか、「GitHub Actions」で定期的に実行したHTMLレポートを限定URL、社内の人だけが見られる場所とかにホスティングして、いつでも見られるようにしておくというようなことをしてあげれば、見る習慣がついてきて、改善の意識が生まれていくのかなという感じです。

テストコード自体の検証

じゃあ今度、テストカバレッジが真の意味でも100パーセントになったとしても、それが本当に意味のあるテストになっているかどうかは断言できないですよという話が、次の話になってきます。

これが最後ですね。「さらにその先へ……」という、Mutation Testによるテストコード自体の検証をしようよというお話です。

まず、「Mutation Testとは？」という話なんですけど。コードの本体に意図的なバグを植えつけることによって、テストコードの検証が適切に行われているかを測定する手法です。

どういうことかというと、カバレッジレポートの罠という話です。まず、この極端なテストケースがあるんですけど、この「addNewOrder」というやつがテストコードの中で実行されている。これはカバレッジとしては100パーセントになるんですけど、検証とかは一切していないため、カバレッジは100パーセントなんですが、正しいテストかと言われるとまったくそんなことはありません。

じゃあ、今度はですね。PHPUnitとかでそういうことをやると、さすがにこれは警告として怒られるというような、さっきの検証がまったくない状況だと怒ってくれることにはなるんですけど。

そうだったとしても、今度は「assertOk」という、単に「200」のレスポンスが返ったよねという検証だけしかないようなテストコードを書いちゃうと、これまた適切な期待する表示がされているかどうかは検証できていないので、それが本当に正しいかどうかはわからない。

ただ、そのテストコード自体は実行されてはいるため、カバレッジの割合は上がっているので、正しいテストができているかは抜きにして、カバレッジの割合は上がっていっちゃうというようなことになります。

Mutation Test

そういうのを解消するのにMutation Testが良いですよというやつで、コードを意図的に変更しますというライブラリがあります。

例えば、この「a===0」というのを「a!==0」みたいなかたちで変異させて、「a===0」のままだったらエラーとならずに終わるんですけど、これが「a!==0」になったらエラーになってくれないといけないはずです。それが、ならずにこけている場所というのは、ちゃんとテストが拾えていないよねというふうにして検証するような手法です。

その指標として、この「Killed」と「Survived」というやつがありまして、失敗すべきテストが失敗したことによって検知された変異の数ですね。これがあるべき姿です。失敗すべきテストがなぜか成功しちゃったという、このSurvivedの数が多ければ多いほど、あんまりちゃんとしたテストコードが書けていないんじゃないか、と判断できるというような指標です。

こいつを導入することによって、2つの使い方があるんですけど。定期実行でプロダクト全体のスコアを見ていって継続的に比較するというようなやり方があります。ただ、これは全体で動かすとけっこう遅いので、週1回程度で動かして、レポートをSlackに投げるみたいな使い方をするのが良いです。

あとは、CIの際にも、差分箇所に対してMutation Testをかけることによって、新たに作られた場所に関しても、ちゃんとしたコードになっているよねというのを都度検証することが可能になります。

ここまで、理屈は話したんですけど、それを実際に自分の業務で導入した経験談という続きが実はあるんですが、お時間が迫っておりますというところなので、実践導入した経験は、また別のカンファレンスにてお話しできればなと思います。

次、「私と会える」と言ったら気色悪いんですけど（笑）。

（会場笑）

直近だと、今度、「PHPカンファレンス香川」だったり、「技術書典」とか、「PHPカンファレンス福岡」とか、「大吉祥寺.pm」とか、さっき告知した、PHP"オレ"カンファレンス神戸で、みなさんと会える機会があるかなと思うのですが。

とりあえず次は、PHPカンファレンス香川でお会いしましょう。というところで、ご清聴あざざました※。

（会場拍手）

（※「あざざます」は、漫画『SPY×FAMILY』の登場人物アーニャのセリフ）