テストコードを書くときには自問自答しよう

　最近テストコードをひたすらレビューしテストコードを運用する視点で色々と考えることが多いことに気づきました。

　どうやったらテストコードを良い感じに書けるのか？というのは難しく、よく「心配事にテストを書くといいよ」と伝えていたのですが、それだとうまく伝わらないなと。

　最近は「単体テストの考え方/使い方」の本が良い感じにまとまってるので助かりますが、それでも読んですぐ実践できるわけでもないのが現実です。

　つまり経験していくと自然と良い感じになっていくのはわかりつつ、テストコードを運用する視点で自問自答するのもひとつの方法と考えたのでいくつか書いてみます。

そのテストコードは落ちて欲しいときにちゃんと落ちますか？

　TDDで開発していれば、必ず落ちるコードを書くところから始めるのでこの罠にハマることがありませんが、後からテストコードを書いたり足したりすると実はそのテストコードは落ちないテストになっている。なんてことがあります。

　また、その逆で実装を少しかえただけで、落ちるはずがないテストが落ちることもあります。

　これらは偽陽性、偽陰性と呼ばれますが、つまりは「落ちて欲しいときにちゃんと落ちますか？」を意識することです。

エラーメッセージの文言を文字列で確認せずにclassがあるかどうかでいいのでは？

　フロント側のテストでフォームのラベルやエラーメッセージが指定した文字列で表示されているかのテストも書きがちですが、エラーメッセージそのものを比較するテストは、文言変更で落ちてしまいます。

　やりたいことは、エラー文言ではなくエラー文言を出しているタグのclassが存在するかどうか。とかで十分なこともあります

表示される文字列チェックテストってやりすぎになってません？

　　さきほどのエラーメッセージと同様です。「この文字列が含まれること」のテストは「仕様で決めた文字列と違うと落ちるから便利！」と思うかもしれませんが、「テキストをXXXに変更して！」と言われるとテストが落ちるのでテストコードをその度に修正することになります。

　つまりテストが落ちて欲しいときに落ちるわけでもなく、テキストの修正に合わせてただテストを修正するだけになります。

　もしテキストでテストするなら動的に何か文字列を生成している場合に、その振る舞いをテストしたいときとかでしょう。

テストコードを書きすぎていませんか？

　テスト書きはじめのころは、あれもこれもテスト書きたくなります。書かないと漏れがあるんじゃないかと不安になるからと推測します。

　しかし、「このテスト本当に必要？落ちてくれたら何がたすかるの？本当に？」ぐらい自問自答して、それでも必要なら書くぐらいでOKです。

　書きすぎたテストコードは将来捨てることになる可能性はとても大きいのです。

と、色々書いてみましたが、他にも自問自答するパターンあると思います。ぜひ皆さんが意識しているパターンを共有して安心してプロダクト開発できる手助けをしてみませんか？