【保存版】単体テスト自動化と静的解析で迷わないための「異常系テストを書く判断基準」完全解説
プログラマーやSEとして開発を続けていると、必ず一度は悩むテーマがあります。それが「異常系テストはどこまで書くべきか？」という問題です。
単体テストの自動化や静的解析を導入すると、正常系テストは比較的スムーズに書けるようになります。しかし、異常系テストになると「これはテストする意味があるのか」「静的解析で十分ではないのか」「工数に見合うのか」と判断に迷う場面が一気に増えます。
この記事では、単体テストの自動化と静的解析を前提とした異常系テストを書く判断基準にフォーカスし、用語の解説から実体験ベースの判断方法、さらに応用的な考え方までを詳しく解説します。現場ですぐ使える内容を意識して書いていますので、ぜひ最後まで読んでみてください。
単体テスト自動化とは何かを改めて整理する
まず前提として、単体テスト自動化について簡単に整理します。
単体テストとは、関数・メソッド・クラスなどの最小単位のロジックが正しく動作するかを検証するテストです。自動化とは、このテストを人の手で毎回確認するのではなく、テストコードとして記述し、CIやローカル実行で自動的に検証できる状態にすることを指します。
私自身、単体テストを本格的に書き始めたのは、手動テストでの確認漏れが原因で本番障害を出してしまった経験がきっかけでした。正常系だけを手動で確認し、「まあ大丈夫だろう」と思ってリリースした結果、想定外の入力で例外が発生し、深夜に呼び出された苦い思い出があります。
その経験から、単体テスト自動化は「安心材料」ではなく、「最低限の品質担保」だと考えるようになりました。
静的解析とは何をしてくれるのか
次に、異常系テストと切っても切れない存在である静的解析について解説します。
静的解析とは、プログラムを実行せずにコードを解析し、問題点や改善点を指摘してくれる仕組みです。代表的なものとして、SonarQube、ESLint、PMD、Checkstyle、FindBugs（SpotBugs）などがあります。
静的解析は主に以下のような問題を検出します。
- NullPointerExceptionが発生しそうな箇所
- 未使用の変数やメソッド
- 条件分岐の漏れ
- 例外の握りつぶし
- コーディング規約違反
私の現場では、静的解析をCIに組み込んだことで、単純なミスによるバグは劇的に減りました。一方で、「静的解析があるから異常系テストはいらないのでは？」という誤解も生まれやすくなりました。
ここが、今回のテーマである異常系テストを書く判断基準が重要になる理由です。
異常系テストとは何かを正しく理解する
異常系テストとは、想定外の入力やエラー条件に対して、プログラムが正しく失敗するかを確認するテストです。
よくある異常系の例としては、以下のようなものがあります。
- nullや空文字が渡された場合
- 数値の範囲外の値が入力された場合
- 存在しないIDを指定した場合
- 外部APIやDBがエラーを返した場合
重要なのは、「異常系＝起きてほしくないケース」ではなく、「起きる可能性がある前提でどう振る舞うか」を確認するテストだという点です。
異常系テストを書くべきか迷ったときの判断基準
ここからが本題です。異常系テストを書くかどうかを判断する際、私が実務で使っている基準を紹介します。
① その異常は実運用で起こり得るか
最初に考えるのは、「本番環境でその異常が起こり得るか」です。
例えば、APIの引数にnullが渡る可能性が、呼び出し元の設計上あり得ないのであれば、異常系テストを書く必要性は低くなります。一方、ユーザー入力や外部システム連携が絡む場合は、想定外の値が入る可能性が非常に高いため、異常系テストを書く価値は高いです。
私は以前、「この値は必ず入る前提だから」と異常系テストを省略した結果、別チームが仕様を変更し、nullが渡るようになって障害を起こした経験があります。それ以来、「自分の想定」ではなく「システム全体として起こり得るか」を基準に判断するようになりました。
② 静的解析だけで十分に検出できるか
次に考えるのは、「その異常は静的解析で十分にカバーできるか」です。
例えば、明らかなNullPointerExceptionの可能性は静的解析が警告してくれます。この場合、同じ内容の異常系テストを大量に書くのは費用対効果が低いことがあります。
ただし、静的解析は「実行時の振る舞い」までは保証してくれません。エラー時に正しい例外メッセージが返るか、ログが出力されるか、呼び出し元に適切に伝播するか、といった点は異常系テストでしか確認できません。
③ 仕様として保証したい振る舞いか
異常時の振る舞いが仕様として重要かどうかも、大きな判断基準です。
例えば、「不正な入力が来たら必ず400エラーを返す」「業務例外の場合は特定のエラーコードを返す」といった仕様がある場合、それは異常系テストで保証すべき内容です。
私の経験上、このタイプの異常系テストがあると、後続のリファクタリングが非常に楽になります。「異常時の仕様が壊れていない」ことを自動で確認できるからです。
異常系テストを書くメリットを具体例で解説
異常系テストを書くことのメリットは、単にバグを減らすことだけではありません。
障害対応のスピードが上がる
異常系テストが揃っていると、障害が発生した際に「どこまでが想定内か」をすぐ判断できます。これは、深夜対応や緊急リリースの際に非常に大きな差になります。
仕様のドキュメント代わりになる
異常系テストは、「この入力が来たらこう振る舞う」という仕様をコードとして残します。私自身、仕様書よりもテストコードを見て仕様を理解することが増えました。
チーム内の認識ズレを防げる
異常系テストがないと、「そこは考慮外」「いや、それは想定内」といった水掛け論が起こりがちです。テストがあれば、その議論自体が不要になります。
応用編：異常系テストを効率よく書くための工夫
最後に、異常系テストをさらに効率的に書くための応用的な考え方を紹介します。
代表的な異常パターンに絞る
すべての異常を網羅しようとすると、テストが肥大化します。私は「境界値」「最も起こりやすい異常」「仕様として重要な異常」に絞ってテストを書くようにしています。
共通処理はテストユーティリティ化する
異常系テストでは、同じようなセットアップや例外検証が繰り返されがちです。これらを共通化すると、テストの可読性と保守性が大きく向上します。
静的解析と役割分担を明確にする
「これは静的解析に任せる」「これはテストで保証する」という役割分担をチームで決めておくと、判断に迷わなくなります。
まとめ：異常系テストは判断基準を持てば怖くない
異常系テストは、闇雲に書くものでも、すべて省略するものでもありません。実運用で起こり得るか、静的解析で十分か、仕様として保証したいか、この3点を基準に判断すれば、無駄なく価値の高いテストを書くことができます。
単体テスト自動化と静的解析を正しく使い分けることで、品質と開発効率は両立できます。この記事が、異常系テストで悩んでいるプログラマーやSEの判断材料になれば幸いです。
コメント