単体テスト（ユニットテスト）とは？その特徴やメリット、活用方法について徹底解説！

単体テストは、システム開発において品質を確保するために不可欠な工程です。

しかし、その定義や目的、やり方を正しく理解していないと、無駄な作業が増えたり、後から大きなバグが見つかって手戻りが発生したりする原因になります。

そこで今回は単体テストとは何かという基本的な知識から、具体的なテストのやり方、さらにはテストの品質を測る指標まで、エンジニアが知っておくべき重要ポイントを網羅的に解説します！

▼テストの種類について詳しい内容はこちら▼

単体テスト（ユニットテスト）とは？

単体テストとは、プログラムを構成する最小単位の部品が、個々に正しく動作するかを検証するテストのことです。

この最小単位は、一般的に「モジュール」や「ユニット」と呼ばれており、具体的には関数やメソッド、クラスといった小さなコードのまとまりを指します。

システム開発のテスト工程は、通常「単体テスト」→「結合テスト」→「システムテスト」という順序で進められますが、単体テストは最も初期段階に位置し、主にコードを書いた開発者自身が担当します。

この段階で、個々の部品に潜むバグや不具合を早期に発見・修正することが主な目的です。

なぜなら、後続のテスト工程に進んでから不具合が見つかると、原因の特定が難しく、修正にかかる時間やコストも大きくなってしまうからです。

たとえば単体テストをしっかり行っておけば、プログラムが正しく動かない原因が他の機能との連携にあるのか、それとも個々の部品自体にあるのかを素早く切り分けられるようになります。

単体テストはその後のテスト工程をスムーズに進めるための土台づくりであり、高品質なシステムを効率的に開発するために不可欠なプロセスです。

他のテスト（結合テスト・システムテストなど）との違い

単体テストの目的や役割をより深く理解するためには、他のテストとの違いを把握することが重要です。

単体テストが個々の部品の品質を担保する「局所的なテスト」であるのに対し、結合テストは複数の部品を組み合わせた際の連携動作に焦点を当てた「連携のテスト」です。

たとえばログイン機能とユーザー情報取得機能を組み合わせたときに、正しくユーザー情報が表示されるかを確認するのが結合テストにあたります。

さらにシステムテストは完成したシステム全体をエンドユーザーの視点で検証する「全体的なテスト」です。

ユーザーが実際に操作する画面や機能が、要件定義書に記載された通りに動くか、性能やセキュリティに問題はないかなどを確認します。

このように、それぞれのテストは目的と検証する範囲が明確に異なっており、テスト工程全体を通して、段階的に品質を高めていく役割を担っています。

こちらは単体テストの基本的な概念を理解するための動画です。

単体テストの仕組み

実施対象（関数・モジュール・クラス）

単体テストは、プログラムを構成する最も小さな部品が正しく動作するかを検証することが目的です。

この「最小単位」は、主にプログラミング言語の仕様や開発プロジェクトの規約によって定義されますが、一般的には関数、メソッド、クラス、モジュールなどがその対象となります。

たとえば、あるWebアプリケーションでユーザーが入力したメールアドレスが正しい形式であるかチェックする機能を実装したとします。

このとき、「メールアドレスの形式を検証する」という特定の処理だけを行う関数やメソッドを単体テストの対象とします。

このテストでは正しい形式のメールアドレスを入力した場合に「検証OK」と返ってくるか、間違った形式や空欄だった場合に「エラー」と返ってくるか、といった複数のパターンを検証します。

重要なのは、その機能が他のプログラムと連携する部分ではなく、その部品単独での動作に焦点を当てるということです。

これにより、もしバグが見つかっても、その原因が特定の関数やクラスにあるとすぐに特定でき、修正が容易になります。

このように、単体テストはソフトウェア開発の早い段階で品質を確保し、後工程での手戻りを減らすための重要な役割を担っています。

ホワイトボックステストとブラックボックステストの観点

単体テストの実施方法を考える上で、ホワイトボックステストとブラックボックステストという2つの観点があります。

これらはテストの「視点」の違いを表しており、それぞれ異なる目的でテストを実施します。

ホワイトボックステストは、プログラムの内部構造に着目してテストケースを設計する手法です。

具体的には、ソースコードの中身をすべて把握した上で、プログラムが通るすべての分岐点（if文やfor文など）を網羅的にテストします。

この方法の目的は、コードの隅々まで実行し、潜在的なバグを洗い出すことです。

一方、ブラックボックステストは、プログラムの内部構造を意識せず入力と出力の結果だけを見てテストする手法です。

たとえば関数に特定の値を入力し、期待通りの出力が返ってくるかを確認します。

これはプログラムがユーザーにとっての「黒い箱」のように内部がどうなっているかわからない状態を想定しているため、「ブラックボックス」と呼ばれます。

この方法の目的は、要件定義や仕様書に基づいて、機能が正しく動作するかを検証することです。

単体テストでは、これら両方の観点を組み合わせて実施することが理想的です。

ホワイトボックステストで内部の処理経路を網羅し、ブラックボックステストで仕様通りの動作を検証することで、より高い品質を確保できます。

例えば、ある関数に異常な値を入力した場合の挙動はブラックボックステスト、その関数の内部にある特定の条件分岐が正しく実行されるかはホワイトボックステストの観点となります。

このように、両方の視点からテストを行うことで、より網羅的にバグを発見することが可能になります。

単体テストのメリット

単体テストを徹底して行うことは、開発プロセス全体に以下のようなメリットをもたらします。

バグの早期発見と修正が可能となる

プログラムの最小単位である関数やクラスの段階で不具合を見つけることで、後工程に進んでから発覚するよりも、修正にかかる時間や労力を大幅に削減できます。

結合テストやシステムテストの段階でバグが見つかると、原因究明に時間がかかり、関連する複数のモジュールを修正する必要が出てくることも少なくありません。

しかし、単体テストをきちんと行っていれば、原因が特定の部品にあるとすぐに特定でき、迅速に対応することが可能です。

コードの品質向上に繋がる

単体テストを前提にコードを書く習慣は、自然と「テストしやすいコード」を生み出します。

これは、一つの関数が複数の役割を持ったり、外部の複雑な要素と密接に結びついているような、テストが難しい「密結合」なコードを避けることになります。

結果として、シンプルで独立性が高く、再利用しやすい「疎結合」なコードになり、保守性が向上します。

リファクタリング（コードの改善）が安全に行える

単体テストが整備されていれば、既存のコードに変更を加えても、テストを実行するだけで、その変更が他の機能に悪影響を与えていないかをすぐに確認できます。

これにより、安心してコードを改善できるようになり、長期的なプロジェクトの健全性を保つことができます。

単体テストのデメリット

単体テストは多くのメリットをもたらしますが、デメリットも存在します。

テストコードを書くための時間と工数がかかる

単体テストを自動化する場合、実際のプログラムコードに加えて、そのテストを行うためのコード（テストコード）を別途作成する必要があります。

プロジェクトの規模が大きくなるほど、このテストコードの作成とメンテナンスにかかる負担は無視できなくなります。

特に、納期が厳しいプロジェクトでは、「テストコードを書く時間があるなら、本番コードを早く完成させたい」という考えになりがちです。

システム全体やモジュール間の連携に関する問題は見つけられない

たとえば、関数単体では正しく動作しても、別の関数と組み合わせたときに予期せぬエラーが発生する場合があります。

これは結合テストの役割であり、単体テストだけでシステム全体の品質を保証することはできません。

テストの実行環境を準備する必要がある

テスト対象のモジュールがデータベースや外部サービスなどの外部依存要素に接続している場合、それらを切り離してテストできるようにスタブ（テスト用のダミーコード）やモック（テスト用の偽オブジェクト）を用意する手間が発生します。

これらを適切に準備しないと、テストが非効率になったり、再現性が失われる可能性があります。

単体テストの種類と観点

制御フローテスト

単体テストの設計手法の一つである制御フローテストは、ソースコードの内部構造に着目し、プログラムのすべての実行経路を網羅的にテストする手法です。

これは、プログラムが分岐やループ（if文やfor文など）によってどのように制御されるか、その「流れ」を追ってテストケースを作成します。

データフローテスト

単体テストのもう一つの重要な観点がデータフローテストです。

これは、プログラム内の変数やデータの流れに着目してテストケースを設計する手法です。

具体的には、「変数がどこで定義（代入）され、どこで使用されるか」というデータのライフサイクルを追跡し、そのデータの流れに問題がないかを検証します。

例えば、ある関数内で変数が定義されたものの、一度も使用されないままになっていたり、あるいは初期化されないまま使用されていたりすると、予期せぬバグの原因となります。

データフローテストは、こうしたデータに関する不具合を効率的に見つけ出すことを目的としています。

データの定義から使用に至るまでのすべての経路をテストすることで、潜在的なエラーやプログラムの効率を妨げる要因を特定します。

データフローテストは、制御フローテストと同様にホワイトボックステストの一種であり、ソースコードの内部を詳細に分析する必要があります。

この手法を取り入れることでプログラムがデータを正しく扱い、期待通りの結果を生成するかどうかを網羅的に確認できます。

これにより、データの破損や誤った計算といった、プログラムの根幹に関わる重大なバグを早期に発見し、ソフトウェアの信頼性を向上させることができます。

境界値分析・同値分割

ブラックボックステストの観点からテストケースを設計する代表的な手法として、同値分割と境界値分析があります。

これらの手法はプログラムの内部構造を知らなくても、仕様書や要件定義書に基づいてテストケースを作成できるため、非常に実用的です。

同値分割は入力データ全体を「同じ結果をもたらす」と考えられるグループ（同値クラス）に分け、そのグループから代表的な値を一つ選んでテストする手法です。

例えば、年齢入力欄が「18歳以上65歳未満」という仕様の場合、有効な同値クラスとして「20歳」、無効な同値クラスとして「15歳」や「70歳」を選び、テストケースとします。

この手法により、テストケースの数を最小限に抑えつつ、効率的にテストを行うことができます。

次に境界値分析は、同値分割で分けたグループの「境界」にあたる値を集中的にテストする手法です。

先の例であれば、「18歳以上65歳未満」という仕様の境界値は「18歳」「17歳」「64歳」「65歳」となります。

プログラムは境界部分でバグが発生しやすいため、これらの値を重点的にテストすることで、より効果的にバグを発見できます。

単体テストでは、これらの手法を組み合わせて用いることで、効率的かつ網羅的にテストを行うことができます。

特に、入力値の検証が必要な単体テストでは、境界値分析と同値分割は欠かせない観点となります。

これにより、少ない工数で高い品質を確保し、後工程での手戻りを削減できます。

単体テストのやり方とテストケース設計

手順（設計 → 実装 → 実行 → 評価）

単体テストは、主に以下の4つのステップで進めることが一般的です。

①テストの設計

まず、テスト対象となるモジュール（関数やクラスなど）の仕様や要件を明確にします。

この段階で、どのような入力値を与えたら、どのような結果が返ってくるべきかを定義します。

具体的なテスト項目（テストケース）を洗い出し、期待される結果を詳細に記述します。

このステップは、単体テストの品質を左右する最も重要なフェーズです。

②テストの実装

次に、設計したテストケースに基づいて、テストコードを作成します。

このテストコードは、テスト対象のモジュールを呼び出し、さまざまな入力値を与えて、期待通りの出力が得られるかを自動的にチェックするものです。

このときテスト対象のコードがデータベースや外部APIといった外部環境に依存している場合は、それらを模倣するダミーのコード（スタブやモック）を用意する必要があります。

③テストの実行

実装したテストコードを専用のテストフレームワーク（JUnit、pytestなど）上で実行します。

テストフレームワークは、テストコードを自動で実行し、各テストケースの合否を判定して結果をレポートとして出力してくれます。

④テストの評価

テスト実行後、出力されたレポートを確認し、失敗したテストケースがないかを確認します。

もし失敗があれば、テスト対象のコードにバグが存在する可能性が高いため、原因を特定して修正します。

修正後、再度テストを実行し、すべてのテストケースが成功することを確認します。

このプロセスを繰り返すことで、モジュールの品質を確実に高めていきます。

これらの手順を一つずつ丁寧に進めることで、テストの網羅性と再現性を高め、効率的な開発に繋げることが可能です。

テストケース作成のポイント

効果的な単体テストを実施するためには、質の高いテストケースを作成することが不可欠です。テストケースを作成する際の重要なポイントは以下の2つです。

正常系と異常系の両方を考慮する

正常系テストは、仕様通りに動作するかを確認するテストです。

例えば、ユーザーIDとパスワードが正しい場合にログインが成功するか、といったケースが該当します。

一方、異常系テストは、予期せぬ入力や不正な操作に対してプログラムが適切にエラーを返すか、クラッシュしないかを確認するテストです。

例えばパスワードを空欄にした場合や、存在しないユーザーIDを入力した場合の挙動を検証します。

この異常系テストを怠ると、予期せぬトラブルにつながる可能性があるため、特に注意が必要です。

境界値と代表値を網羅する

例えば「18歳以上65歳未満」という入力条件がある場合、その境界である「18歳」と「64歳」はもちろん、その隣の「17歳」と「65歳」もテストケースに含めることが重要です。

また境界値だけでなく、「25歳」や「50歳」といった代表的な値もテストすることで、より幅広いケースをカバーできます。

単体テストの設計では、これらの観点を意識してテストケースを洗い出すことで、抜け漏れのない質の高いテストが実現できます。

コードレビューとの関係

単体テストとコードレビューは、どちらもソフトウェアの品質を向上させるための重要なプロセスですが、それぞれ異なる役割を持っています。

単体テストは、プログラムが仕様通りに動作するかを機械的に検証するためのものです。

一度作成したテストコードは繰り返し実行できるため、開発中の機能追加や修正によって意図しないバグが発生していないか（回帰テスト）を継続的に確認できます。

これにより、再現性のある客観的な品質保証が可能になります。

一方、コードレビューは、人間による多角的な視点からコードの品質をチェックするためのプロセスです。

単体テストでは見つけにくい、以下のような問題を発見できます。

このように、単体テストが「正しく動くか」を客観的に評価するのに対し、コードレビューは「より良いコードか」を主観的・経験的な視点から評価します。

この二つは決して対立するものではなく、相互に補完しあう関係にあります。

単体テストによって動作の保証を行い、コードレビューによって設計や可読性を高めることで、ソフトウェアの全体的な品質をさらに引き上げることができます。

単体テストをしっかり書くことでレビューが効率的になるというメリットも生まれます。

単体テストの自動化

自動化するメリット

単体テストの自動化は、ソフトウェア開発において以下のようなメリットをもたらします。

効率と生産性の向上

手動でテストを実行する場合、何度も同じ手順を繰り返す必要があり、時間と労力がかかります。

しかし、テストを自動化すれば、一度書いたテストコードを何度でも、迅速かつ正確に実行できるようになります。

これにより、開発者はテストにかける時間を大幅に削減し、本来の業務であるコードの実装に集中できます。

品質の安定と向上に貢献

自動化されたテストは、手動テストで起こりうる見落としやミスを防ぎ、テスト結果の一貫性を保ちます。

特に新しい機能を追加したり、既存のコードを修正する際に、リグレッションテスト（回帰テスト）を自動的に実行することで意図しないバグが発生していないかを常にチェックできます。

これにより、システムの品質を高いレベルで維持できます。

開発チーム全体のコラボレーションを促進

テストが自動化されていれば、誰がいつテストを実行しても同じ結果が得られるため、プロジェクトの透明性が高まります。

さらにテストコードは、そのコードがどのように使われるべきかを示すドキュメントとしての役割も果たします。

新しくチームに加わったメンバーが、テストコードを読むことで、既存の機能の仕様を素早く理解できるようになります。

よく使われるフレームワーク（JUnit、pytest、xUnit系）

単体テストを自動化するためには、テストフレームワークと呼ばれる専用のツールを利用することが一般的です。

各プログラミング言語には、それぞれ適したテストフレームワークが存在します。

ここでは、代表的なフレームワークをいくつか紹介します。

JUnit

Java開発で広く使われているのがJUnitです。

JUnitは、Javaの単体テストを効率的に行うための標準的なツールであり、アノテーション（@Testなど）を使ってテストメソッドを簡単に定義できます。

JUnitは、Java開発者にとって必須ともいえるフレームワークです。

pytest

Pythonでは、pytestが非常に人気です。

pytestは、シンプルな構文でテストコードを書くことができ、プラグインが豊富で拡張性が高い点が特徴です。

また、pytestは、Python標準ライブラリのunittestよりも簡潔に記述できるため、多くの開発者に好まれています。

xUnit系

これらのフレームワークは、まとめてxUnit系と呼ばれることがあります。

xUnit系のフレームワークはそれぞれが持つ共通の設計思想に基づいており、テストの実行、結果の検証、レポート出力といった基本的な機能を提供します。

例えばテストコードが失敗した場合に、どのテストが失敗したのか、なぜ失敗したのかを詳細に報告する機能は、どのxUnit系フレームワークでも共通して利用できます。

CI/CDとの連携

単体テストの自動化は、CI/CD（継続的インテグレーション/継続的デリバリー）パイプラインと組み合わせることで、その真価を発揮します。

継続的インテグレーション（CI）

継続的インテグレーション（CI）とは、開発者が自分のコードを中央リポジトリに頻繁にマージする開発手法のことです。

CI環境では、開発者がコードをプッシュするたびに、自動的にビルドとテストが実行されます。

この自動テストに単体テストを組み込むことで、バグが本番環境にデプロイされる前に、ごく初期の段階で発見・修正することが可能になります。

継続的デリバリー（CD）

継続的デリバリー（CD）は、CIでビルドとテストが完了したコードを、いつでも本番環境にデプロイできる状態に保つ開発手法です。

CDパイプラインに単体テストを組み込むことで、デプロイのたびに自動で品質チェックが実行されるようになります。

CI/CDと単体テストを連携させるメリット

まず、手作業によるテストの頻度が減り、開発サイクルが加速します。

コードの変更が自動的にテストされるため、手動でテストを行う手間が省けます。

次に、バグを早期に発見できることで、修正にかかるコストが最小限に抑えられます。

最後に、品質管理が自動化されるため、エンジニアは品質を気にすることなく、新機能の開発に集中できます。

このように、単体テストの自動化はCI/CDと密接に連携し、現代のソフトウェア開発において不可欠な要素となっています。

単体テストの品質を測る指標

カバレッジの種類（命令網羅・分岐網羅・条件網羅）

単体テストの品質を測る指標として最も一般的に使われるのが、カバレッジ（網羅率）です。

カバレッジとは、作成したテストケースが、テスト対象のコードをどれだけ網羅しているかをパーセンテージで示したものです。

カバレッジにはいくつかの種類があり、それぞれ異なる観点から網羅度を測定します。

命令網羅（C0）

プログラムのすべての命令文（ステートメント）が、一度は実行されるようにテストケースを設計する手法です。

これは最も基本的なカバレッジであり、コードが書かれた通りに実行されるかを確認します。

命令網羅率が100%ということは、すべてのコード行がテストされたことを意味します。

分岐網羅（C1）

プログラム内のすべての分岐（if文やswitch文など）において、真（True）と偽（False）の両方の経路が一度は実行されるようにテストケースを設計する手法です。

命令網羅よりも厳密な基準であり、単純なコード実行だけでなく、条件分岐のロジックが正しく機能するかを確認します。

分岐網羅率が100%であれば、すべての分岐先がテストされたことになります。

条件網羅（C2）

プログラム内の複合的な条件式（if A and Bなど）に含まれる個々の条件が、それぞれ真と偽の両方になるようにテストケースを設計する手法です。

分岐網羅よりもさらに厳密で、複雑な条件式の論理的な正しさを検証します。

例えば、「Aが真、Bが真」「Aが真、Bが偽」「Aが偽、Bが真」「Aが偽、Bが偽」といったすべてのパターンを網羅することを目指します。

これらのカバレッジは、テストの網羅性を客観的に評価する上で非常に有効な指標です。

カバレッジと品質保証の関係

カバレッジは、単体テストの品質を保証するための重要な要素です。

カバレッジ率が高いほど、より多くのコードがテストされており、それだけバグが見つけられる可能性が高まります。

プロジェクトによっては、「カバレッジ率80%以上」といった具体的な目標値を設定することも珍しくありません。

この目標値を設定することで、開発者はテストに対する意識を高め、より網羅的なテストケースを作成するようになります。

これにより後工程で発覚するバグを減らし、プロジェクト全体の手戻りを最小限に抑えることができます。

高いカバレッジ率は開発チームが品質に対して高い意識を持っていることの証明にもなり、クライアントや上司からの信頼獲得にもつながります。

しかし、単にカバレッジ率を高めることだけが目的になってしまうと、質の低いテストケースが量産されるリスクもあります。

例えば、単にテスト対象のコードを実行するだけで、結果の検証を行わないテストケースは、カバレッジ率を高めることには貢献しますが、バグの発見には役立ちません。

カバレッジはあくまでも「テストの網羅性」を測る指標であり、「品質」そのものを直接保証するものではないことを理解しておく必要があります。

過信してはいけないポイント

カバレッジは単体テストの品質を測る上で非常に有用な指標ですが、カバレッジ率が高いからといって、バグがまったくないわけではないという点を理解しておくことが重要です。

カバレッジを過信すると、以下のような問題点を見落とす可能性があります。

バグの存在を保証するわけではない

カバレッジは「テストが実行されたコードの量」を示しますが、「テストが正しく動作したか」までは保証しません。

例えばテストケースに誤りがあり、本来失敗すべきテストが成功している場合、カバレッジ率は高くてもバグは残ったままになります。

カバレッジ100%でもバグはゼロにならないことを理解しておく必要があります。

仕様の抜け漏れは発見できない

カバレッジは、あくまで「書かれたコード」に対する網羅性しか測れません。

そもそも仕様書に記載されていない機能や、考慮漏れがあった場合には、テストコード自体が作成されないため、カバレッジ率には反映されません。

これにより、仕様の抜け漏れに起因するバグは発見できません。

プログラムの全体像は測れない

カバレッジは単体テストの指標であり、モジュール間の連携やシステム全体の動作は測定できません。

単体テストでバグがなくても、複数のモジュールを連携させた際に不具合が発生する可能性はあります。

このように、カバレッジはあくまでも一つの指標に過ぎません。

カバレッジを有効活用しつつも、ブラックボックステストの観点や、他のテスト工程と組み合わせることで、より包括的にソフトウェアの品質を管理していくことが重要です。

まとめ

今回は単体テスト（ユニットテスト）の基本的な概念から、具体的なテスト手法、メリット・デメリット、そして自動化や品質指標との関係までを解説しました。

単体テストは、プログラムの最小単位の品質を担保するための重要なプロセスであり、開発の初期段階でバグを早期発見・修正する役割を担っています。

結合テストやシステムテストといった後続のテスト工程との違いを理解し、それぞれの役割を正しく認識することが、高品質なシステムを効率的に開発するための第一歩です。

テストコードを書くことには時間と工数がかかりますが、その初期投資は、後工程での手戻り削減や、コードの保守性向上という形で、大きなリターンをもたらします。

さらに、JUnitやpytestといったテストフレームワークを活用してテストを自動化し、CI/CDと連携させることで、開発プロセス全体の効率を飛躍的に高めることができます。

このようなテストの種類や内容を正しく理解し、実践することで、プロジェクトの品質を担保できるエンジニアとして、社内からの信頼も獲得できるようになるでしょう！

QA業務効率化ならPractiTest

テスト管理の効率化についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで工数を20%削減できる総合テスト管理ツール「PractiTest」がおすすめです！

この記事の監修

Dr.T。テストエンジニア。
PractiTestエバンジェリスト。
大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。
2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。

記事制作：川上サトシ