単体テストとは？手法と観点のポイントを解説

以前の記事でシステム開発におけるテスト工程の重要性を解説しましたが、今回は「単体テスト」について、さらに詳しく掘り下げていきます。
単体テストは、システム開発における最も基本的で重要なテスト工程であり、コードの品質や動作を保証するための重要なステップです。
プロジェクトや文化によって単体テストのアプローチは異なりますが、どのような形であれ、品質保証の基盤となる部分です。

単体テストとは

単体テストとは、開発したプログラムの最小単位（モジュールやクラスなど）を単独でテストする工程です。プログラムや機能単位の動作の確認を行うことを目的として行うテストです。
通常、モジュールやクラスごとにテストケースを作成し、それぞれのテストケースで期待される動作や結果を定義します。ここで発見された不具合は確認範囲が限定的なため、開発者が自身のコードをテストすることで、バグや不具合を早期に発見し対応しやすくなります。

また、前回のブログでも触れましたが、V字モデルにおいては「詳細設計」と「単体テスト」は対になっています。
「詳細設計」で決めたモジュール単位の具体的な仕様に基づいて、「単体テスト」を実施します。
詳細設計の品質が、単体テストの質を大きく左右します。詳細設計を曖昧にすると、単体テストの範囲や精度も下がります。
このように、単体テストと詳細設計は互いに影響しあうため、両者を明確に関連付けることが重要です。この段階で不具合やバグをできる限りつぶしておくことで、以降のテスト工程での手戻りを防ぐことができ、システム全体の品質向上につながります。

単体テストのアプローチの違い

プロジェクトや文化によって、単体テストのアプローチが異なる場合があります。
例えば、フロントエンド（FE）とバックエンド（BE）の両方でユニットテストを書き、コード単体のテストを行う場合もあれば、単画面テスト（FEとBEが結合された状態）を単体テストと呼ぶ場合もあります。
このようにチームの開発フローやテスト環境に応じて、テストのアプローチを柔軟に決めることができます。
ツールや方法もいろいろですが、どのツールや方法を使うとしてもプロジェクト内で「単体テストの目的と観点と範囲」の認識を合わせておくことは大事だと思います。

単体テストで行われる一般的なテスト手法

以下はシステム開発の現場で、単体テストの際に広く使われているテスト手法です。

単体テストでは、主に次のような手法を使って『テストケースの設計』を行います。それぞれのテストの中には、さらに細かな具体的手法があります。
・ ホワイトボックス系手法（制御フロー、データフロー）
・ ブラックボックス系手法（同値クラス、境界値、状態遷移、エラー処理）

また、単体テストを行う上での『環境作りや依存関係の切り離し』に関する手法としては、
・ モックテスト（外部依存をモック化）
・ インターフェーステスト（外部との入出力を独立確認）

などがあります。

ホワイトボックステスト

ソースコードの内部構造に着目して行うテストで、コードの内部構造を理解したうえで実施するテスト手法です。モジュールや関数内部の動作を検証します。
具体的には以下の手法があり、それぞれの観点から品質を確認します。

• データフローテスト
  データフローテストは、「定義（初期化）→使用→消滅」のライフサイクルが正しく処理されていることを確認するテスト手法です。
  以下のように、データ操作におけるエラーを検出することを目的としています。
  データフローテストは主に コードレビューやデバッグ実行、テストコード（ユニットテスト） によって実施します。
  ・ 未定義の変数が使われることがないか
  ・ データの上書き処理が適切か
  ・ 初期化されずに使われる変数はないか
  ・ 一度も使用されないまま消滅している変数はないか

• 制御フローテスト
  制御フローテストは、プログラム内部の「分岐」や「繰り返し」などの制御構造が、設計通りに動作しているかどうかを確認するテスト手法です。
  一般的に、以下の観点でチェックします。
  ・ 命令網羅: テスト対象のプログラム内のすべての命令を一度は実行すること。
  ・ 分岐網羅: 条件分岐を一度は実行し、すべての分岐をカバーすること。
  ・ 条件網羅: 条件分岐における条件式の組み合わせすべてをテストすること。

ブラックボックステスト

ブラックボックステストとは、ソースコードの内部構造を意識せずに、仕様書をもとに外部から入出力の妥当性を確認するテスト手法です。
各機能が仕様通りに動作するかを自動化したテストコードで確認したり、画面単位のテストとしてユーザーが入力した内容が正しく反映されるかを、実際の画面を通じて手動でテストすることもあります。
ホワイトボックステストだけでなく、ブラックボックステストも併用することで、内部仕様と外部仕様のずれを見つけることができます。

• 同値クラステスト
  同値クラステストは、入力データをグループ化し、それぞれの代表値を使ってテストを行う方法です。
  例えば、条件a >= 10 && a <= 20の場合、「10未満」「10～20」「20より大きい」の3つの同値クラスに分けて、それぞれの代表値でテストします。
• 境界値テスト
  同値クラスの境界にあたる値でテストを行う手法です。
  例えば条件a >= 10 && a <= 20の場合、
  境界値として「9」「10」「11」「19」「20」「21」といった値をテストします。
  9→×
  10→○
  11→○
  19→○
  20→○
  21→×境界付近では特にエラーが発生しやすいため重要なテストです。
• 状態遷移テスト
  システムの状態が仕様通りに変化（遷移）するか確認するテストです。例：「ログイン前→ログイン後」や「送信ボタン押下→送信完了画面」の遷移などを確認。
• エラーハンドリングテスト
  異常なデータや操作を入力した際に、システムが適切にエラーを処理するか確認します。例：必須項目を未入力のまま送信した場合のエラー表示を確認。
• フロントエンド画面テスト
  画面設計書に基づいて、UIが仕様どおりに表示され、入力値が適切に処理されるかを確認します。
  主な確認項目
  ・ レイアウト、色、アイコン、画像、ヘッダー・フッター
  ・ ボタンやフォームの動作
  ・ 入力項目のバリデーション（未入力、異常値）
  ・ エラーメッセージの表示の妥当性

単体テスト仕様書（参考サイト）
テストコード書く場合や納品物に含まれていないなど、作成しない場合もありますが、
一般的に単体テストを進める際は、具体的なテスト項目や期待結果を記載した「単体テスト仕様書」を作成します。
いくつか参考サイトを掲載します。
単体テスト仕様書の書き方サンプル（テクバン株式会社）
単体テスト仕様書兼結果報告書テンプレート（Creative Content Lab Tokyo）
単体テストとは？目的・観点・項目・エビデンスを簡単に説明する