![単体テスト](https://offshore.icd.co.jp/blog/wp-content/uploads/2025/01/unittest.jpg)
あなたは、システム開発における開発工程の一部である単体テストについて具体的にどのようなことをしているのか、どのように進めたら良いのか気になっているところではないでしょうか。よく比較されがちな結合テストやシステム(総合)テストと何が違うのか、その辺りも含めてシステム開発会社として25年経つ会社に所属している私が解説します。
本記事を読んでいただき、システム開発における単体テストについて、少しでも理解に繋がる材料となれると幸いです。
目次 [非表示]
1.単体テストの目的とは?
開発が終わった後にまずは単体テストを実施します。そんな単体テストについて、1章ではどんなテストをするのか概要を説明します。
1-1.単体テストは、機能単体の動作をテストすること
単体テストは、開発した機能単体の動作をテストすることです。開発したエンジニアがそのまま単体テストをするケースが多く、その機能単体がどのような動作をするのが正解か明確なはずです。そのため、より正確なテストをすることができるでしょう。
1-2.単体テストは、テスト工程の最初に位置する
単体テストは、テスト工程の中でも最初に実施するテストとなっています。その次に結合テスト、総合テスト…と続きます。
各工程を以下のように略して呼ぶこともあるので、ここで覚えておくと良いでしょう。
工程 | 略称 | |
RD | Requirement Definition | |
BD | Basic Design | |
DD | Detail Design | |
UT | Unit Test | |
IT | Integration Test | |
ST | System Test | |
OT | Operation Test |
システム全体の流れについては以下の記事で紹介していますので、ご参考ください。
「システム開発の開発工程とは?10個のフェーズに分けて解説」
1-3.結合テストと総合テストとの違い
それでは、結合テスト/総合テストと何が違うのか紹介します。簡単に表にまとめると以下の通りです。
名称 | 工程 | 対象 | 内容 |
単体テスト | 最初のテスト | 機能単体 | 機能単体で不具合なく動作するかテスト |
結合テスト | 単体テストの次 | 機能単体 + 機能単体 | 機能と機能を組み合わせた時に不具合なく連動して動作するかテスト |
総合テスト | 結合テストの次 | システム全体 | 要件定義で設定した要件に沿った動作をするかテスト |
上記の通り、テストは3段階に分けて実施していきます。単体テストをクリアしても結合テストでエラーになることもあり、その場合は単体テストに戻ってエラーの原因を探りにいくことになります。そのエラーを放置して先に進めると欠陥があるシステムとなってしまうので、エラーは必ず解消しなければなりません。
2.単体テストの進め方
2章では実際に単体テストをどのように進めたら良いか紹介したいと思います。
2-1.単体テストするための仕様書を作成する
単体テストを行うための仕様書をまずは作成しましょう。この仕様書は要件定義書等とは別で、単体テスト専用の仕様書になります。どのような機能があって、その機能に対してどのようなテストをするのか、どのような観点でテストするのが良いか、整理しておく必要があります。
- 要件定義書をもとに単体テストが必要な機能を洗い出す
- 単体テストの手法を記載
- 単体テストの観点を記載
- どのような条件(環境)で実施するか
2-2.単体テストをするためのモジュールを準備する
単体テストをするために各モジュールのスタブとドライバを準備します。
スタブ:テスト対象となる機能Aの後にある機能Bをダミーとして設けること(トップダウンテスト)
ドライバ:テスト対象となる機能Bの前にある機能Aをダミーとして設けること(ボトムアップテスト)
2-3.単体テストを実行する(ホワイトボックステスト/ブラックボックステスト)
2-1で作成した仕様書をもとに単体テストを実行していきます。ここで不具合が発生したときは、コードを修正します。コードを修正したら、必ず修正したコードが及ぼす範囲すべてを再テストする必要があります。
テストの手法として、ホワイトボックステストとブラックボックステストの2種類があります。
ホワイトボックステスト:プログラムの内部構造を理解・意識した上で、それらが正しい構造で意図した通りに動作しているかを確認するテストです。
ブラックボックステスト:プログラムの内部構造を考慮せず、ユーザー要求を仕様通り満たしているかを確認するテストです。
詳細については、以下の記事で取り上げています。
「ホワイトボックステスト、ブラックボックステストの違いとは?」
2-4.単体テストの結果を記録する
単体テストの記録として、ログや入力/出力したデータを残しておくようにしましょう。後工程で、何か不具合が起きた時にどのようなテストをして、どのような結果が出たのか結果を見返すこともあるでしょう。テストしたエンジニアと別の人が見返すこともあるので、他人が見ても分かるように整理しておく必要があります。
3.単体テストで見るべき観点
それでは、単体テストでは2章で作成した仕様書に基づいて、何を確認すれば良いのか紹介します。
主には以下の項目について確認することができます。
- テスト対象のプログラムを実行した際に期待通りの返り値が出るかどうか
- テスト対象のプログラムを実行した際に例外が発生するかどうか
- テスト対象のプログラムを実行した際に発生する副作用は想定通りか など
この項目を機能ごとに確認していくことになります。
4.単体テストで失敗を避けるためのポイント
4章では単体テストを実施するのにあたり、失敗を避けるポイントを紹介します。
4-1.単体テストを自動化する
単体テストを自動化することで、人為的なミスを極力減らすことができます。また、短時間で多くのテストを実行できるので効率的とも言えます。
自動化のためには、テスト用のフレームワークを活用します。例えば、Java → Junit、PHP → PHPUnit、Python → PyUnitなどがあります。使用している言語に基づいて適したフレームワークを調べてみましょう。
4-2.テストの範囲を明確にする
様々なパターンでテストするほど精度の高いモノができますが、時間が決まっているのですべてのパターンを実施する猶予はないことが多いです。そのため、どこまでの範囲を単体テストするか予め仕様書で定めておきましょう。
また、単体テストでは確認できないこともあるので、そのような部分は単体テスト以降のテストで確認するようにしましょう。
⇩ 単体テストでは確認できないこと ⇩
テスト対象のプログラムのパフォーマンスが十分かどうか
テスト対象のプログラムを修正で、システムの仕様が修正されたかどうか など
「単体テスト」まとめ
システム開発における単体テストについて解説してきました。単体テストは、開発後のテスト工程として最初に来るテスト工程になります。開発した人がそのまま単体テストも対応することが多く、単体テストでNGだった場合はコードを書きなおして解消されるまでやります。
そんな単体テストについてまとめてきましたが、弊社は会社を立ち上げたから25年が経ちます。長年の経験からシステム開発の手段について様々アドバイスできると思います。システム開発で行き詰った時には、どんな些細なことでも、お気軽にお問い合わせいただければと存じます。相談は無料です!