Webアプリやシステム開発で避けて通れない「単体テスト」。
しかし、実際にテストケースを作ろうとすると「どのくらいの量を用意すればいいのか？」という壁にぶつかります。テストを増やせば網羅性は上がりますが、その分コストも膨らみます。一方で減らしすぎれば、見落としが多くなり品質を損ねるリスクがあります。
そこで本記事では、単体テストケースの「量の考え方」をわかりやすく整理し、実務での現実的な目安を紹介します。正常系・異常系・境界値の考え方や、リスクベースでの優先順位付けなど、バランスを取るためのヒントを具体例を交えて解説していきます。
単体テストとは、プログラムの最小単位（関数やメソッド）が仕様通りに動作するかを確認するテストです。
テストケースの量が問題になるのは以下の理由からです。
つまり「やろうと思えばキリがない」のが単体テスト。だからこそ、どこまでやるのかを合理的に決める必要があります。
テストケースの最小単位は、正常に動作するケース と 異常な入力をした場合のケース の2つです。
user@example.com → 登録できるuserexample.com（@なし） → エラーになるuser@@example.com（@2つ） → エラーになるこのように、1つの機能に対して「成功パターン」と「代表的な失敗パターン」を用意するのが最低限です。
入力値の上限や下限など、境界値 はバグが発生しやすいポイントです。
境界値を1つでも見落とすと、重大な不具合につながりかねません。そのため「正常＋異常」に加えて「境界」を意識することが重要です。
単体テストを作る際は、すべてを均等にテストする必要はありません。
重要なのは「バグが出ると影響が大きい処理」に多めのテストケースを割くことです。
リスクが高いところに重点を置き、リスクが低い部分は最低限にするのが現実的です。
テストケースの量を数値で判断する方法の一つが コードカバレッジ です。
現場では、70〜80%程度のカバレッジ を目安にすることが多いです。
100%を目指すと工数が爆発するため、コストに見合う範囲で設定するのがポイントです。
プロジェクトの規模や重要度によって、単体テストの量は変わります。
テストケースを際限なく増やすのではなく、リスクベースのアプローチ が有効です。
これにより「品質」と「コスト」のバランスを保つことができます。
テストケースを増やしていくと、管理が課題になります。ドキュメント化の方法としては次のような手段があります。
単体テストケースの量には「正解の数」はありません。
しかし次の基準を意識すれば、現実的で効果的な範囲を設定できます。
やみくもに増やすのではなく、限られたリソースの中で「重要なところに集中する」ことが、単体テストの効率化と品質向上につながります。