対象試験と出題頻度
単体テスト(ユニットテスト)は、基本情報技術者・応用情報技術者で出題されるテーマです。
ソフトウェア開発のテスト工程に関する問題で定番化しており、「結合テスト」「システムテスト」「受入テスト」との違いや、内部構造に着目するホワイトボックステストの技法(命令網羅・分岐網羅など)と組み合わせて問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★★☆
ランクA(重要)必ず覚えておくべき
用語の定義
情報処理試験を勉強していると、「単体テストって何をテストするの?結合テストとどう違うの?」と混乱しがちです。
単体テスト(Unit Test)とは、一言で言うと
「プログラムを構成する最小単位(モジュール・関数・クラス)が、単独で正しく動くかを検証するテスト」
のことです。
イメージとしては、「車を組み立てる前の部品検査」です。
エンジン、タイヤ、ハンドル……車に組み込む前に、それぞれの部品単体で「ちゃんと動くか」を一つひとつ検査しますよね。
組み立ててから不具合が発覚すると、原因の切り分けが大変です。
単体テストも同じで、プログラム全体を組み合わせる前に、関数1つずつが期待通りに動くかを確かめる作業です。
📊 単体テストの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Unit Test / Module Test |
| テスト対象 | 関数・メソッド・クラス・モジュールなど最小単位 |
| 主な技法 | ホワイトボックステスト(命令網羅・分岐網羅など) |
| 実施者 | 主にプログラマー本人 |
| 代表的なツール | JUnit(Java)、pytest(Python)、PHPUnit(PHP)など |
解説
ソフトウェアは数千〜数百万行のコードで構成されます。完成品を一気にテストして不具合が出た場合、どこに原因があるか特定するのに膨大な時間がかかります。
そこで開発工程では、小さな単位から順に検証を積み上げていく方針が取られます。最初の関門が単体テストです。
V字モデルでの位置づけ
開発工程とテスト工程の対応関係を表すV字モデルでは、単体テストは「プログラム設計(詳細設計)」に対応します。
V字モデルとテスト工程の対応
左右の対応関係(同じ高さ=対応する工程)
| 要件定義 | ⇔ | 受入テスト |
| 外部設計 | ⇔ | システムテスト |
| 内部設計 | ⇔ | 結合テスト |
| プログラム設計 | ⇔ | 単体テスト |
▲ 左側を上から、右側を下から読むと「V」の形になる。底辺(プログラム設計⇔単体テスト)が最も詳細な工程
ホワイトボックステストの主要技法
単体テストでは、内部のロジックを把握した上でテストケースを設計するホワイトボックステストが中心になります。代表的な網羅基準は以下の通りです。
| 網羅基準 | 条件 | 強さ |
|---|---|---|
| 命令網羅 | すべての命令文を最低1回実行する | 弱 |
| 分岐網羅 (判定条件網羅) |
各分岐の真/偽を最低1回ずつ通る | 中 |
| 条件網羅 | 各条件式の真/偽を最低1回ずつ満たす | 中 |
| 判定条件/ 条件網羅 |
分岐網羅と条件網羅を同時に満たす | 強 |
| 複数条件網羅 | 条件式の真偽の組み合わせをすべて網羅する | 最強 |
スタブとドライバ
テスト対象モジュールが他のモジュールを呼び出している場合、まだ未完成の部品を「仮のもの」で代用する必要があります。
スタブ(Stub):テスト対象から呼び出される「下位モジュール」の代役。決まった値を返すだけの簡易実装。
ドライバ(Driver):テスト対象を呼び出す「上位モジュール」の代役。引数を渡して実行するだけの簡易実装。
スタブとドライバの位置関係
[1]本来のモジュール階層(呼び出しの向き)
(例:注文処理)
(例:金額計算)
(例:消費税計算)
▼ 上下が未完成のとき、代役を立てる ▼
[2]単体テスト時:未完成部分を「代役」で置き換える
上位の代役:テスト対象を呼び出すだけの仮実装
下位の代役:固定値を返すだけの仮実装
| 代役 | 位置 | 役割 | 呼び出しの向き |
|---|---|---|---|
| ドライバ | テスト対象の上 | テスト対象を呼び出す | ドライバ → テスト対象 |
| スタブ | テスト対象の下 | テスト対象から呼ばれて値を返す | テスト対象 → スタブ |
覚え方:「呼ぶ側がドライバ(運転手)、呼ばれる側がスタブ(半券)」
テストコードの例(JUnit)
実際のテストコードがどのようなものか、Javaの代表的な単体テストフレームワークJUnitの例を示します。
// テスト対象クラス
public class Calculator {
public int add(int a, int b) {
return a + b;
}
}
// テストコード
import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;
public class CalculatorTest {
@Test
void 正の数同士の足し算が正しく計算される() {
Calculator calc = new Calculator();
int result = calc.add(2, 3);
assertEquals(5, result); // 期待値と実測値が一致するか検証
}
@Test
void ゼロを含む足し算が正しく計算される() {
Calculator calc = new Calculator();
assertEquals(0, calc.add(0, 0));
}
}
assertEquals(期待値, 実測値) のように「こうなるはず」という期待値と、関数を実行した結果を比較します。
一致すれば成功、ズレていれば失敗としてレポートされます。
他のテスト工程との比較
| テスト工程 | 対象 | 主な観点 |
|---|---|---|
| 単体テスト | 関数・モジュール単体 | 内部ロジックが仕様通り動くか |
| 結合テスト | 複数モジュールの組み合わせ | モジュール間のインタフェースが正しいか |
| システムテスト | システム全体 | 機能要件・非機能要件を満たすか |
| 受入テスト | 完成したシステム | 発注者の要求を満たすか(発注者が実施) |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 単体テストの核心を3行で
・関数・クラス・モジュールなど最小単位が単独で正しく動くかを検証する工程
・ホワイトボックステストの技法(命令網羅・分岐網羅など)で内部ロジックを網羅する
・上位の代役がドライバ、下位の代役がスタブ
試験ではこう出る!
単体テストは、FE・APの午前問題でテスト工程の区別やホワイトボックステスト技法と組み合わせて頻出しています。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| FE R元秋 午前 問47 |
単体テストで使用するスタブとドライバの説明として正しいものを選ぶ問題。 | ・上位=ドライバ、下位=スタブ ・上下を入れ替えたひっかけが定番 |
| AP H30秋 午前 問49 |
命令網羅・分岐網羅・条件網羅・複数条件網羅の包含関係を問う問題。 | ・複数条件網羅が最も強い ・命令網羅が最も弱い |
| FE H29春 午前 問48 |
ホワイトボックステストの説明として正しいものを選ぶ問題。 | ・「内部構造に着目」がキーワード ・「仕様に基づく」はブラックボックス |
| AP R4春 午前 問46 |
テスト工程と検証対象の対応を問う問題。 | ・単体テストはモジュール単位 ・結合テストはモジュール間インタフェース |
📝 IPA試験での出題パターン
パターン1:「スタブとドライバの区別」
FE R元秋のように、上位モジュールの代役(ドライバ)と下位モジュールの代役(スタブ)を入れ替えて出題されるのが定番。「上のド、下のス」と語呂で覚えると確実です。
パターン2:「網羅基準の強弱」
命令網羅 < 分岐網羅 < 判定条件/条件網羅 < 複数条件網羅 の包含関係が問われます。具体的なフローチャートを与えられて「最低何通りのテストケースが必要か」を計算させる問題も頻出です。
パターン3:「テスト工程の対応」
V字モデルで「単体テストはどの設計工程に対応するか」を問う形式。プログラム設計(詳細設計)に対応する点を押さえてください。
試験ではここまででOKです。テスト駆動開発(TDD)やモック・フェイクの細かい区別までは深追い不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. ソフトウェア開発における単体テストの説明として、最も適切なものはどれでしょうか?
- A. 完成したシステム全体を発注者の業務環境で動作させ、要求仕様を満たしているかを発注者が確認するテストである。
- B. 複数のモジュールを組み合わせ、モジュール間のインタフェースが仕様通りに連携するかを検証するテストである。
- C. プログラムを構成する関数やクラスなどの最小単位が、単独で仕様通りに動作するかを検証するテストである。
正解と解説を見る
正解:C
解説:
単体テストはモジュール・関数・クラスといった最小単位を対象に、内部ロジックが仕様通りに動くかを検証する工程です。主にプログラマー本人が実施し、ホワイトボックステストの技法を用います。
選択肢Aは受入テスト(承認テスト)の説明です。発注者側が業務シナリオで検証する最終工程であり、最小単位を対象とする単体テストとは段階が異なります。選択肢Bは結合テストの説明です。モジュール間のインタフェース検証が目的であり、単一モジュール内のロジックを確かめるものではありません。
よくある質問(FAQ)
Q. テスト駆動開発(TDD)と単体テストは同じものですか?
違います。TDDは「テストコードを先に書いてから本体コードを実装する」という開発スタイルの名前で、単体テスト自体を指す用語ではありません。TDDの中で書かれるテストの多くがユニットテストフレームワーク(JUnit、pytestなど)で実行される、という関係です。IPA試験ではTDDという用語自体は時折登場しますが、単体テストの定義そのものとは切り分けて理解してください。
Q. モック(Mock)はスタブと何が違いますか?
スタブは「決められた値を返すだけ」の単純な代役ですが、モックは「呼び出されたときの引数や回数を記録し、想定通りに呼ばれたかを検証できる」高機能な代役です。例えば「DB保存処理が1回だけ呼ばれること」を確認したい場合、モックを使います。実務ではMockitoなどのライブラリで作りますが、IPA試験の範囲ではスタブとドライバの区別ができれば得点上は十分です。
Q. カバレッジ(網羅率)はどのくらいを目標にすべきですか?
プロジェクトによりますが、一般的なWebアプリ開発では命令網羅で70〜80%が一つの目安です。100%を目指すとテストコードのメンテナンスコストが膨大になり、費用対効果が悪化します。金融や医療など人命や大金が絡む領域では、より厳しい網羅基準(複数条件網羅)と高いカバレッジ率が要求されます。試験では具体的な数値より「網羅基準の強弱関係」が問われるため、そちらを優先して覚えてください。
Q. CI/CDと単体テストの関係は?
CI(継続的インテグレーション)の中核がユニットテストの自動実行です。GitHub ActionsやJenkinsなどのCIツールが、コードがプッシュされるたびに自動でテストを走らせ、失敗したらマージをブロックします。これにより「壊れたコードがmainブランチに混入する」事故を防げます。AP午前ではCI/CDの基本概念が問われることがあるため、「自動化されたテスト=単体テストが中心」という関係を押さえておくと安心です。