システム開発における開発工程の一部である単体テストについて具体的にどのようなことをしているのか、どのように進めたら良いのか、よく比較されがちな結合テストやシステム（総合）テストと何が違うのか、その辺りも含めて解説していきます。
本記事を読んでいただき、システム開発における単体テストについて、少しでも理解を深めていただけると幸いです。
目次 [非表示]
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 |
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だった場合はコードを書きなおして解消されるまでやります。
- 「単体テストを自動化して業務効率化したい…」
- 「テスト工程だけでも外部委託を検討しているが、切り出しでお願いできるものか…」
- 「そもそも単体テストやったことなくて、何をやれば良いか分からない…」
こんなお悩みありませんか…
弊社はお客様に合わせて様々な体制を組むことが強みでもあり、オフショア開発、ニアショア開発、オンサイト（常駐型）開発、受託開発など…お客様の状況に合わせてご提案いたします。相談は無料！なのでお気軽にお問い合わせください。