2018.03.05

テストコードはどれくらい書くべきか

doiken

MMMバックエンドエンジニアの土居です。
現在はNode.jsの案件に携わっており、ニガテなJavaScriptの勉強中ですがとても楽しいです。

必要十分なテストとは

テストコードはシステムの品質を担保するためにとても重要です。
しかし、プロジェクトが立て込んでいるときなど時間的に余裕が無いときは実装を優先し、テストコードは最低限にせざるをえないことはままあるかと思います。
そういった状況において、どのような（どれくらい）テストを書くのが必要十分なのか、ということを考えてみました。

テストコードのコスト

テストコードを書くこと自体はやはり一定のコストはあると思います。
検証したい対象のコードに対して複数パターンのテストケースを書くことになると思いますので、コードを書く時間は確実に増加します。
しかし、テストコードが整備されていることによって、実装時に修正や新たに加えた機能が思わぬところへ影響を及ぼしていないか（デグレ）を確認しつつ次の実装を進めることができるのは手戻りが減ったりなど効率的な面もあり、総合的な開発時間は単純にテストコードを書いた分増加しているわけではないと感じます。
また、継続して自社でメンテナンスしていったり、まだまだ機能の追加が行われていくシステムである場合は上で述べたような総合的な時間におけるメリットをさらに得られる（回収できる）と考えられます。
先日議論していた中で聞いた意見でなるほどと思ったものでは、コードレビューが効率的になるというのもありました。
大量のPRを捌いていくときなど、どうしても徹底的に全コードを背景や影響範囲まで含めてチェックするのは厳しいといった状況はあります。
そうした場合にテストコードで仕様が担保されているのかを確認しやすくなっていると、スムーズにレビューができそうです。

優先したいテスト(回帰テスト)

不要なケースを書きすぎたりさえしなければ、基本的には書くほど品質の担保率は上がっていくのかなと思いますが、ここでは優先して実装すべきテストコードについて考えてみたいと思います。
前項のコストのところで述べたメリットから考えると、優先して実装すべきものとしては回帰テストが挙げられると思います。
APIでいえばControllerのエンドポイントからレスポンス内容レベルでの検証など、最終的な仕様を確認するテストを最低限のものとして準備しておくのが重要かなと感じます。

余裕があれば。。なテスト

if, switchといった条件分岐による内部構造をケース分けしたテストは本来の単体テストという意味でいうともちろん必要なのですが、あまりこれらを完璧に整備するのはけっこう大変です。。
そのためには、そもそも実装の時点でミスを減らすために個人のプログラミング精度を上げたり、またはできるだけシンプルな設計を意識し、複雑さを回避できれば理想的です。

テスト対象の重要性

これまで優先すべき/そうでもないテストについて考えてみましたが、対象システムの重要性によっては話が変わってくることもあると思います。
経験したことは無いですが、例えば人命に関わるようなシステムであればそれは内部構造についても完璧なテストが必要になるでしょうし、逆に止むを得ずバグが発生してから対応するを善しとすることもあるでしょう。
ちなみに、前職で長期間、継続的に利用されるSC向け顧客分析システムの開発を行なっていた時は、レシート情報を元にした計算ロジックの箇所などはテストデータのパターンで様々なケースを用意していた記憶があります。