単体テストとは？初心者向けに基本から種類・やり方まで徹底解説

---

単体テストとは、プログラムを構成する一つひとつの部品が正しく動作しているかを確認するテストです。コードの品質を保ち、バグを早期に発見できるため、ソフトウェア開発に欠かせない工程といえます。本記事では、単体テストの基本的な考え方から種類・観点・手順までを、分かりやすく解説します。

---

単体テストとは

単体テストとは、ソフトウェアの最小単位（関数、メソッド、クラスなど）が正しく動作するかを検証するテストのことです。プログラム全体ではなく、個々の部品が設計通りに機能するかを確認します。

例えば、電卓アプリを開発する場合、受け取った数値を合計する「足し算処理」、先に受け取った数値から後に受け取った数値を引く「引き算処理」といった個別の処理ごとにテストを行います。これにより、問題が発生した際に原因の特定が容易になり、修正コストを大幅に削減できます。

単体テストは、開発の初期段階で実施されることが多く、コーディング直後に行うのが一般的です。バグを早期に発見できるため、後工程での手戻りを防ぎ、開発効率を向上させる重要な役割を果たします。

では、よく比較される結合テストとはどう違うのでしょうか。

単体テストと結合テストの違い

単体テストと結合テストの最も大きな違いは、テストの範囲です。

単体テストは、先述の通り個々の処理を独立して検証します。一方、結合テストは、単体テストで動作確認された複数の処理を組み合わせて、それらが意図通りに連携して動作するかを検証するテストです。例えば、「ログイン処理」と「データベース接続処理」が正しく連携しているかを検証します。

主な違いを整理すると以下の通りです。

比較項目	単体テスト	結合テスト
テスト範囲	最小単位 (関数、メソッド)	複数処理の組み合わせ
実施タイミング	コーディング直後	単体テスト完了後
目的	個別処理の正確性	インターフェースの整合性
発見できるバグ	ロジックエラー	連携エラー

このように、単体テストは品質保証の最初のステップとして位置づけられます。では、なぜ単体テストがこれほど重要視されるのでしょうか。

なぜ単体テストを行うのか？

単体テストを行う最大の理由は、バグの早期発見とコスト削減です。開発の初期段階でバグを見つけることで、修正にかかる時間とコストを大幅に抑えられます。

具体的なメリットは以下の通りです。

1. バグの早期発見：単体テストでは、コーディング直後に問題を検出できます。後工程で発見されるバグと比較して、修正コストは約1/10とも言われています。
2. コード品質の向上：各モジュールが仕様を満たしていることを保証することで、ソフトウェア全体の品質向上に貢献します。
3. リファクタリングの安全性：既存のコードを改善する際、単体テストがあれば「改修によって既存機能が壊れていないか」を素早く確認できます。これにより、安心してコード改善に取り組めます。

単体テストは必ずと言っていいほど、どのプロジェクトでも実施される重要なテストです。単体テストの重要性を踏まえて、次はその具体的な手法を確認していきましょう。

代表的なテスト手法

ソフトウェアテストには、代表的な2つのテスト手法があります。ホワイトボックステストとブラックボックステストという2つのアプローチです。それぞれ異なる視点からテストを行い、両方を組み合わせることでより網羅的な検証が可能になります。

ホワイトボックステスト

ホワイトボックステストは、コードの内部構造を見ながらテストを設計する手法です。プログラムのロジックや分岐、ループ処理などを把握した上で、すべての経路が実行されるようテストケースを作成します。

主な技法：

• 命令網羅（C0）：プログラム中のすべての命令文を1回以上実行
• 分岐網羅（C1）：すべての分岐を1回以上実行
• 条件網羅（C2）：個々の条件式の真偽をそれぞれ1回以上実行

ブラックボックステスト

ブラックボックステストは、コードの内部構造を見ずに、仕様書に基づいてテストを設計する手法です。入力値と期待される出力値の関係のみに注目します。

主な技法：

• 同値分割：期待される出力が同じとなる入力値を、ひとつのグループ（同値クラス）にまとめて、代表値のみをテスト
• 境界値分析：仕様条件の境界となる値やその隣接する値を重点的にテスト（〇〇未満、〇〇以上）
• デシジョンテーブル：ソフトウェアの複雑な条件と結果の組み合わせを「デシジョンテーブル（決定表）」で整理し、それに基づいて網羅性の高いテストケースを作成する手法

単体テストでは、関数やメソッドといった小さな単位のコードを検証するため、内部構造を詳しく確認できるホワイトボックステストがメインとなります。コードの論理的な経路やエッジケースを漏れなくテストすることで、バグの早期発見につながります。ただし、必要に応じてブラックボックステストの技法も組み合わせることで、内部ロジックと外部仕様の両面から品質を保証できます。次は、実際にどのような観点でテストすべきかを見ていきましょう。

単体テストの観点

単体テストの手法を理解したところで、「実際にどんな視点でテストすべきか」という具体的な観点を解説します。単体テストでは、以下の4つの観点から網羅的にテストケースを設計することが重要です。

• テスト対象
• 検証方法
• 入力条件
• 出力結果

これらの観点は、テスト設計において重要な切り口として広く認識されており、漏れのないテストケース作成に役立ちます。

テスト対象

システムやアプリケーションの中で、テスト対象となる関数・メソッド・クラスなどの処理単位を特定する観点です。どの処理ロジックを検証するのかを明確にすることで、テスト範囲を整理できます。

テスト対象の具体例：

• 金額計算処理（税計算、端数処理、四捨五入　など）
• 日付計算処理（うるう年や、存在しない日付を正しい月末日に直す補正 など）
• バリデーション処理（必須項目の確認、入力形式や値の範囲チェック など）

検証方法

テストにおいて、どのように正しさを判断するかを定義する観点です。処理によって異なりますが、具体的には次のような検証方法があります。

主な検証方法：

• ホワイトボックステスト（分岐網羅など）

入力条件

どのようなデータでテストするかを定める観点です。同値分割や境界値分析などの手法を用いて、代表的な入力パターンを設計します。

入力条件の例：

• 数値：境界値（最小値、最大値）、ゼロ、負数
• 文字列：空文字、null、文字数制限、特殊文字
• 日付：存在しない日付（2月30日）、うるう年、月末日

出力結果

各テストケースにおいて、期待される結果（出力）を明確に定義する観点です。単体テストでは戻り値だけでなく、内部状態の変化や外部呼び出しの有無も含めて確認します。

出力結果の例：

• 戻り値：計算結果が仕様通りの値で返ること
• 状態変化：オブジェクトのプロパティが正しく更新されていること
• 外部呼び出し：モック経由で期待するメソッドが呼ばれていること

出力結果は、テスト前に明確に定義しておくことが重要です。「なんとなく動いた」ではなく、「期待通りの結果が得られた」と判断できる基準を設けましょう。

これら4つの観点を組み合わせることで、網羅的なテスト設計が可能になります。次のセクションでは、これらの観点を踏まえた具体的なテストの進め方を見ていきましょう。

単体テストのやり方

観点を理解したところで、実際の単体テストの進め方を3つのステップで解説します。これは一般的な流れの一例であり、業界やプロジェクトの特性によって省略されるステップもあります。参考として、ご自身の状況に合わせてご活用ください。

1. テスト仕様書の作成

単体テストでは、テスト内容を明確にするための方法がいくつかあります。プロジェクトの特性や開発手法によって、最適なアプローチは大きく異なります。

形式的なテスト仕様書を作成する場合：医療、航空宇宙、金融などの規制が厳しいドメインや、大規模なウォーターフォール開発では、何をどのようにテストするかを文書化したテスト仕様書を作成します。これは開発された処理に対して、正しくテストが行えていることを紐づけるためです。

テスト仕様書に含まれる項目の一例：

項目	内容
テストID	TC001など、一意の識別子
テスト項目名	「正常な日付入力の検証」など
前提条件	テスト実行前に必要な状態
入力値	具体的なテストデータ
実行手順	テストの実施方法
期待結果	正しい動作の定義
実施結果	OK/NG (実施後に記入)

テストコードをドキュメントとして活用する場合：アジャイル開発やTDD（テスト駆動開発）を採用している環境では、テストコードそのものがテスト仕様書の役割を果たします。テストコードの名前や構造を工夫することで、「何をテストしているか」が明確になり、別途文書を作成する必要がありません。

その他の方法：小規模プロジェクトでは、スプレッドシートやチケット管理ツール、チーム内の口頭合意で済ませることもあります。

どの方法を選択するかは、プロジェクトの規模、開発手法、規制要件、チームの慣習などによって決まります。重要なのは、チーム全体がテストの内容と意図を共有できることです。

テスト内容を明確にする際は、前章で解説した4つの観点（テスト対象、検証方法、入力条件、出力結果）を踏まえることが重要です。

2. 単体テストを実施

テスト仕様書に基づいて、実際にテストを実行します。自動テストと手動テストの2つのアプローチがあります。

自動テストの場合：

• テストコードを作成
• テストフレームワークで実行

手動テストの場合：

• テスト環境を準備
• テスト仕様書の手順に従って実行

3. テスト結果をまとめる

テスト結果を報告する必要のあるプロジェクトでは、テスト実施後、結果を整理して記録します。実行結果（エビデンス）は、ログや入出力したファイルも併せて保存しておきます。テスト結果がNGだった場合は、プログラムを修正して、再度単体テストを実施します。この修正とテストを繰り返し、すべてのテストケースがOKとなることを確認します。

次のセクションでは、これまでの内容を具体的な例を用いて確認していきましょう。

単体テストの具体例

ここまでの理論を踏まえて、実務でよく遭遇する2つの具体例を見ていきましょう。実際のイメージを持つことで、単体テストへの理解が深まります。

例1：日付のフォーマット変換関数

機能概要：「2025-11-12」形式の日付を「2025年11月12日」形式に変換する関数

テスト観点：

• 正常な日付文字列の変換
• 不正な形式の日付の処理
• 存在しない日付（2月30日など）の処理
• null、空文字の処理

テストケース例：

テストID	入力値	期待結果
TC001	"2025-11-12"	"2025年11月12日"
TC002	"2025-11-31"	エラー (存在しない日付)
TC003	"abc"	エラー (不正な形式)
TC004	null	エラー (null入力)

このテストでは、境界値分析（月の1日と月末）や同値分割（有効/無効な日付）の技法を活用します。

例2：ショッピングカートの割引計算関数

機能概要：購入金額に応じて割引を適用する関数

• 5,000円未満：割引なし
• 5,000円以上10,000円未満：5%割引
• 10,000円以上：10%割引

テスト観点：

• 境界値での計算精度
• 負の金額の処理

テストケース例：

テストID	入力値 (円)	期待結果 (円)
TC001	4,999	4,999 (割引なし)
TC002	5,000	4,750 (5%割引)
TC003	9,999	9,500 (5%割引)
TC004	10,000	9,000 (10%割引)
TC005	-100	エラー (負の金額)

このテストでは、境界値分析が特に重要で、金額のしきい値前後で正しく動作するか確認します。

これらの具体例から、テスト設計の考え方が見えてきたのではないでしょうか。次は、実際にテストを実施する際の注意点を見ていきましょう。

単体テスト実施の際の注意点

単体テストを効果的に実施するために、押さえておくべき重要な注意点を2つ解説します。

1. テスト範囲を明確にしておく

単体テストにはできることとできないことがあります。そのため、適切な範囲でテストを実施することが重要です。

単体テストで検証できること：

• 個別処理のロジックが正しいか
• 入力値に対する出力値が期待通りか
• エラー処理が適切に動作するか
• 境界値での動作が正確か

単体テストで検証できないこと：

• 複数処理の連携動作
• パフォーマンスや負荷耐性
• ユーザビリティ
• セキュリティ脆弱性の全般

2. 単体テストは万能ではない

単体テストは重要ですが、これだけで品質が保証されるわけではありません。単体テストは品質保証の一部であることを理解しましょう。

実際の運用環境での問題や複数機能の統合時に現れる問題など、単体テストでは検出できない課題も存在します。そのため、結合テスト、システムテスト、受け入れテストなど、他のテストと組み合わせることが重要です。

また、テストカバレッジ100%を目指すよりも、重要な処理やリスクの高い部分を重点的にテストする方が現実的です。テストの目的は「バグをゼロにすること」ではなく、「許容可能なレベルまでリスクを下げること」です。

ただし、安全性が極めて重要なシステム（自動車の制御システム、医療機器、航空機システムなど）では例外です。これらの分野では、人命に関わるため、法規制や業界標準によって100%の命令網羅や、より厳格なMC/DCなどの高水準のカバレッジが要求されます。

まとめ

単体テストは、ソフトウェアの最小単位を検証する重要なプロセスです。ホワイトボックステスト手法を活用し、テスト対象・検証方法・入力条件・出力結果の4つの観点から網羅的にテストケースを設計することが重要です。単体テストだけでは品質を保証できないため、結合テストやシステムテストと組み合わせて実施しましょう。まずは小さな関数から単体テストを始めて、品質の高いソフトウェア開発を実現してください。

---