1 ユニットテストの概要
1.1 定義と目的
1.1.1 最小単位の検証
ユニットテストは、ソフトウェアを構成する最小単位を対象として、その振る舞いが仕様どおりであることを確認するための検証手法である。対象は関数、クラス、モジュール、単体コンポーネントなど、設計上の粒度に応じて定められる。最小単位を狙うことで、原因切り分けの手がかりを得やすくなり、変更点と挙動の対応を追跡しやすくなる。
1.1.2 早期検知と回帰防止
コード変更により既存の振る舞いが崩れることを「回帰」と呼ぶが、ユニットテストはその兆候を早期に発見することを主目的とする。開発者が変更後に即座へ実行して確認できる場合、問題の発生源を小さな範囲に絞り込める。さらにテストが継続的に再実行される環境では、過去の期待仕様が守られているかを継続的に点検できる。
1.2 他のテストとの関係
1.2.1 結合テストとの違い
結合テストは複数のユニットを組み合わせたときの動作を検証するのに対し、ユニットテストは個々の構成要素の内部ロジックや責務を中心に確認する。ユニットテストでは外部依存を制御し、入力と出力、状態遷移、例外の扱いなどを対象化する。一方、結合テストでは連携仕様に重心が移り、インタフェースの整合や通信、データ整形の正しさが検証領域となることが多い。
1.2.2 システムテストとの役割分担
システムテストは、アプリケーション全体を統合した状態で要件に対する整合性を評価する。ユニットテストが「部品の正しさ」を支えるのに対し、システムテストは「利用者の目的を満たすこと」を確認する性格が強い。実務では、ユニットテストが不具合の局所化に寄与し、システムテストはユーザー観点の重要シナリオを扱うことで全体の効果が高まる。
1.2.3 受け入れテストとの整合
受け入れテストは、利用側の観点や契約条件に基づき、受け入れの可否を判断する。ユニットテストはその前段として、要件に含まれるロジックの単位を検証する役割を担う。整合を取るには、ユニットテストを要件の具体的な挙動へ分解し、どのテストがどの要求に対応するかを見える化することが有効になる。
2 設計と考え方
2.1 テスト対象の切り分け
2.1.1 関数単位のテスト観点
関数を対象とする場合、主要な観点は入力、出力、状態の変化、例外、並行性に関わる振る舞いである。引数の組み合わせに対して戻り値が期待どおりか、入力が検証されるか、エラー条件で適切な例外が投げられるかを中心に据える。副作用を持つ場合は、変更される領域や更新順序も検証対象に含める。
2.1.2 クラス・モジュールの責務分割
クラスやモジュールでは、責務の境界がテスト設計の起点になる。公開メソッドの仕様、内部状態、依存先との協調を整理し、責務ごとにテストを配置することで粒度が保たれる。責務が混在すると、1つの失敗が複数の原因候補を生みやすくなり、診断性が下がる。そのため、単体としての意味が明確な単位に切り分ける設計が重要になる。
2.2 テスト容易性（保守性）
2.2.1 結合度を下げる工夫
テスト容易性を高めるには、テスト対象と周辺要素の結び付きを弱める発想が必要である。具体的には、依存の受け渡しを引数やインタフェース経由にし、内部で直接生成しないなどの工夫が有効になる。結合が強い場合、変更が波及してテストの更新コストが増え、結果としてテストが形骸化しやすい。
2.2.2 依存関係の管理
依存関係の管理は、外部資源や他モジュールをテストの外へ退避させる設計と関係する。たとえば入出力、ネットワーク、データベース、乱数、時刻などの「変動しやすい要素」を境界として切り、置き換え可能な形にしておくと、再現性のあるテストを構築しやすい。加えて、依存の向きが一貫していることは、将来の拡張時にもテストを維持しやすくする。
2.3 典型的なテストケース設計
2.3.1 正常系・異常系
正常系は期待された入力に対する通常の結果を確認し、異常系は不正入力や障害条件での振る舞いを検証する。異常系では、エラーが検知されること、適切な戻り値や例外、メッセージ、ログの生成方針が守られることなどを点検する。正常系だけに偏ると実運用での劣化に気づきにくくなり、異常系だけでも品質の全体像を捉えにくい。
2.3.2 境界値と例外パス
境界値は、仕様上の切り替わりが発生しやすい値域の近辺に置かれる。例として上限・下限、長さの最小/最大、閾値比較の境目などがある。例外パスは、異常時に実行される分岐を対象にするため、通常の経路とは異なる後始末や状態保持が正しいかを確かめられる。境界と例外を組み合わせることで、見落としが減る。
2.3.3 仕様ベースの網羅
仕様ベースの網羅は、実装の書き方ではなく、要件や仕様の観点からテストの範囲を定める考え方である。たとえば「計算式の前提条件」「入力の許容範囲」「出力の形式」「エラー時の規約」などをテスト項目へ落とし込む。網羅性を高めるほどテスト数は増えがちだが、重要な観点から段階的に拡張し、保守可能な量に調整することが実務では重要になる。
3 実装の実務
3.1 テストフレームワーク
3.1.1 アサーションの考え方
アサーションは、実行結果が期待値に一致することを判定するための仕組みである。比較対象は戻り値だけでなく、変更された状態、呼び出し回数、引数、例外の種類や発生タイミングなどにも及ぶ。望ましいのは、失敗したときに何が違ったのかが追える形で記述することである。さらに、意味の薄い比較を増やし過ぎると、誤差や揺らぎに弱くなるため注意が必要である。
3.1.2 テスト実行とレポート
テストフレームワークは、テストの実行順、結果の集計、失敗情報の提示などを担う。レポートには、失敗したテストの識別子、期待と実際の差、スタックトレース、必要に応じてログの抜粋が含まれる。CIなどの自動環境では、この情報が開発者の調査コストを左右する。したがって、テストの設計段階から、診断に必要なコンテキストが取得できる形に整えておくことが求められる。
3.2 モック・スタブ・フィクスチャ
3.2.1 モックの使いどころ
モックは、依存先の振る舞いを置き換えつつ、呼び出しの有無や引数、順序などを検証するために用いる。ユニットの責務が「外部への働きかけ」に含まれる場合に適している。たとえば、サービスが別コンポーネントへ通知を送るか、条件によって呼び出しを抑制するかを確認するのが典型である。過度な検証に寄ると実装の詳細に縛られ、リファクタリングの自由度が下がるため、検証粒度の設計が重要になる。
3.2.2 スタブによる制御
スタブは、依存先の戻り値や例外発生をあらかじめ決めておき、テスト対象の経路を制御する手段である。モックが「相互作用」の検証に重点を置くことが多いのに対し、スタブは「入力に応じた応答の再現」に寄る。外部資源へのアクセスを避け、再現性を確保しながら、正常系・異常系の複数シナリオを効率よく検証できる。
3.2.3 テストデータの準備
テストデータは、入力の作成、状態の復元、期待結果の生成を支える材料である。フィクスチャと呼ばれる共通の準備処理を活用すると、重複を減らしつつ一貫性を担保できる。データはテスト間で共有しすぎると副作用の温床になるため、必要な範囲で隔離する。とくに可変なオブジェクトは、各テストで新規生成するか、リセット可能な設計にして整合性を保つ。
3.3 テストの読みやすさ
3.3.1 テスト名の付け方
テスト名は、何を検証し、どの条件で、どんな結果が期待されるかが短く分かる形が望ましい。読解の手間が減るほど、レビューや障害調査の速度が上がる。命名が抽象的すぎる場合、失敗しても状況が掴めず、調査に時間がかかる。逆に詳細すぎる場合は改修時に追随しにくいため、バランスを取る。
3.3.2 失敗時の診断性
診断性は、テストが失敗したときに次のアクションが立てやすいかを指す。期待値と実際値の差を明確に示し、関連する入力条件をログやメッセージに含めると効果が高い。さらに、例外の種類だけでなく、どの分岐で発生したかが分かるように書くと原因特定が早まる。診断性のための情報設計は、テストコードを「実行仕様の記録」として扱う姿勢につながる。
3.3.3 冗長さの抑制
冗長なテストは読みづらく保守しにくい。繰り返しの多い準備処理は共通化しつつ、テストの意味が薄まらないように切り分ける。アサーションが過剰だと失敗時の意味が散り、重要な違いが埋もれる。したがって、主要な性質に絞って検証し、補助的な確認は別テストへ分離するなどの整理が有効になる。
4 運用と品質管理
4.1 自動化と継続的インテグレーション
4.1.1 実行タイミング（ローカル・CI）
ユニットテストはローカル実行で素早いフィードバックを得る用途がある一方、CIで自動実行して品質の揺らぎを抑える。ローカルでは開発者の修正直後に確認し、CIでは統一された環境で再現性を担保する。両者は役割が異なるため、同一のテストスイートを用いつつも、CIでは追加の解析や静的検査と組み合わせる設計が多い。
4.1.2 テストの並列化と安定性
並列化は実行時間の短縮に寄与するが、テスト同士の干渉があると不安定化する。共有データ、同一ポートの利用、固定名のファイル生成などが原因になりやすい。安定性のためには、テスト実行単位ごとの隔離、乱数や時間の固定、外部依存の遮断を徹底する。さらに、依存するリソースの取り合いを避け、実行順へ依存しない書き方に整えることが重要になる。
4.2 カバレッジ指標と限界
4.2.1 コードカバレッジの考え方
コードカバレッジは、テスト実行によってどれだけの行や分岐が実行されたかを示す指標である。数値はテストの網羅状況を直感的に把握する助けになるが、万能ではない。たとえば分岐が通過したとしても、そこでの妥当性確認が弱い場合があるため、カバレッジはあくまで補助的な観点として位置づけるのが一般的である。
4.2.2 有効性はカバレッジだけでは測れない
有効性は、期待された仕様を確実に守っているか、失敗の原因を局所化できているか、重要な条件で品質を守れているかで判断されるべきである。カバレッジが高くても、アサーションが弱い、誤った入力が検証されていない、境界値が欠けているなどの問題が残りうる。逆にカバレッジが低くても、重要な経路が深く検証されていれば品質に寄与することがあるため、評価は多面的に行う必要がある。
4.3 フレーク（不安定）対策
4.3.1 時刻・乱数依存の排除
テストの不安定化は、時刻や乱数のような変動要素への依存から起きやすい。例えば現在時刻を用いた計算、乱数に基づく選択、タイムアウトの厳密な時間測定などが該当する。対策として、入力を固定し、依存先を注入できるようにして制御することがある。結果が毎回同じになることを優先し、観測対象を明確化する。
4.3.2 外部要因の隔離
外部要因には、ネットワーク遅延、ファイルシステム状態、並行プロセスの影響などが含まれる。ユニットテストの領域では、可能な限りこれらを遮断し、置換可能な境界を通じて応答を制御する。たとえば外部呼び出しはスタブやモックで置換し、ファイル操作は一時領域に閉じる。隔離が不十分だと、失敗が再現できず、開発の信頼性が損なわれる。
4.4 ベストプラクティス
4.4.1 「少ないが強い」テストの設計
「少ないが強い」は、過剰な数ではなく、重要な性質を確実に検証する発想である。主要な分岐、境界、仕様の核心となる振る舞いを優先し、重複する確認を整理することでテストの価値を上げる。弱い検証が大量にある状態は、失敗時に情報が薄くなりやすい。強い検証を少数で積み上げることが、保守と品質の両立につながる。
4.4.2 リファクタリングと同時改善
テストはコードと同様に進化する対象であり、リファクタリングと同期して整えることが重要になる。構造を改善する際にテストが追随していないと、意図せずテストが壊れたり、逆に誤った仕様を追い続けたりすることがある。改善のタイミングで観点を整理し、テストの意図が現状の設計に合っているかを見直すと効果が高い。
4.4.3 レビュー観点と改善サイクル
テストコードもレビュー対象であり、読みやすさ、診断性、依存の扱い、境界条件の網羅などを観点として確認する。加えて、失敗が起きたときの運用—原因究明のしやすさ、修正後の再発防止—を改善サイクルとして回すことが品質維持に直結する。テストを「単なる合格条件」としてではなく、「仕様の実行可能な説明」として扱う姿勢が、継続的な改善を支える。