「Javaの鉱脈」でPITの記事を書きました
WEB+DB PRESS の Vol.90 で、ミューテーションテストの記事を書いたので是非読んでくださし。
2015/12/23 発売ですので、既に購入頂いてる方も多いと思います。
今回は、git の記事とドラクエの記事がスゲェ面白いのでメガッサオススメです。
電子書籍版もありますので物理的な媒体に興味がない方は PDF を買って下さい。
今回の記事における対象読者について
今回の記事は JUnit によるユニットテストは書いていて、Maven なり Gradle なりでコードカバレージを CI サーバで取るくらいのことはしているという皆様に読んで頂きたいと考えています。
記事の内容について
中身はどうあれ JUnit 使ったユニットテストを書くというのは、みなさんやってると思うんですよね。 アサーション全くしてねぇとか、標準出力で結果確認してるとか、例外系全くやってねぇとか、そういう話はあるにしても、一応ユニットテストらしきものは書いている。
そういう状況で次の一歩を踏み出すツールとしてコードカバレージの取得ってのはあるんですけども、単純にコードカバレージとるだけだと、テスト対象コードをとりあえず動かしさえすれば良い事になってしまいます。
動かすだけ動かしててもアサーションの無いユニットテストじゃ、テストとして不足していると言わざるを得ません。
そこで、ミューテーションテストです。ミューテーションテストは雑に言うならば、テストをテストするためのツールです。
最後に
僕は設計のために書いたテストコードらしきアレと、品質保証のために書いているテストコードと混ぜないで欲しいって話をたまにします。
一方で、多くの開発現場ではそんな事言ってられませんってのも現実です。 そこで、設計のために書いたけど、もう要らないのにコンピューティングリソースを無駄食いしてるやつらを自動的に弾きだす方法を紹介しようってわけです。
ミューテーションテストは偽陽性みたいな事になるパターンがあるので、完全に自動化するって訳にはいきませんけども、レビューする際のとっかかりとしてツールの問題なのかどうか議論するのは悪くないと考えます。