ソフトウェア開発では、開発フェーズによって単体テスト、結合テスト、システムテストなどタイプの異なるテストが実施されます。今回はその中から、単体テストについてその目的やメリット・デメリット、具体的な手法などをご紹介します。
単体テストとは？
「単体テスト」は、コンポーネントテスト、ユニットテスト（UT）とも呼ばれ、ソフトウェア開発の最初に実施されるテストです。例えば、ウォーターフォール型のソフトウェア開発で広く用いられる手法である「V字モデル」では、開発工程（要件定義、基本設計、詳細設計）の各工程に対応するテスト工程（システムテスト、結合テスト、単体テスト）が定義されており、単体テストは「詳細設計」に対して行われるテストです。例としてV字モデルを挙げましたが、開発手法に関わらず単体テストから結合テスト、システムテストという順に小さな単位からシステム全体へとテストを進めていきます。
単体テストはテスト可能な最小単位からテスト対象とすることができますが、一般的にはモジュールやコンポーネント単位でテストを実施します。モジュールやコンポーネント単位でのテスト実施には、テスト対象のモジュールを呼び出す下位モジュールの代わりとなる「スタブ」や、上位モジュールの代わりとなる「ドライバ」を使うため、単体テストではそれらの準備が必須となります。
単体テストを行うメリット・デメリット
ここで、単体テストのメリット・デメリットを整理しておきましょう。
単体テストのメリット
- モジュールやコンポーネント単位でテストを行うため、原因の特定と修正が容易
- 開発の早い段階で不具合を発見・修正することができ、結合テスト以降のフェーズでのテストの安定性が向上する
単体テストのデメリット
- 作成した開発者自身が単体テストを実施することが多く、開発工数に負担がかかる
単体テストは開発工数への負担が大きいことから、工数が十分に確保できずテストが省略されたり不完全なテスト実施になりがちです。しかし、開発の後工程で不具合が見つかるほどその修正にかかる工数とスケジュールへの影響が甚大になることから、単体テストを実施することには大きなメリットがあります。
結合テストがどのような単位で実施されるか、モジュール・コンポーネントが流用なのか新規開発かなど、プロダクトの状況を考慮しながらテスト対象を決定し、単体テストの時点でどこまでテストするかを判断して、バランスよく単体テストを実施することが大切です。
単体テストの手法
単体テストでは、ホワイトボックステストとブラックボックステスト、双方のテストアプローチを用います。
ホワイトボックステスト
ホワイトボックステストは、システムとプログラムの内部構造に視点を当てたテストで、コードの命令や分岐の網羅率などに焦点をあててテストを行います。
ホワイトボックスのテスト技法については、以下の記事に詳細に記載してありますので、そちらを参照してください。
ブラックボックステスト
ブラックボックステストは、内部構造を考慮せずに仕様を満たしているかどうかを検証するもので、インプットとアウトプットに焦点をあててテストを行います。単体テストでは、「同値分割（同値クラス）」「境界値分析」といったテスト技法を用います。
テスト技法1：同値分割（同値クラス）
同値分割（同値クラス）は、入力・選択対象を同じ動作をする条件の集まりとしてクラス化（パーティション化）し、それぞれのクラスに対してテストを行う技法です。
例えば、以下の判定式があった場合、
0～19歳：未成年
20～64歳：現役
65歳～：高齢者（前期後期高齢者）
対象を「未成年」「現役」「高齢者」という3つにクラス化し、それぞれの有功値内から任意の値を1つ選択してテストを行います。各クラスの代表値でテストして欠陥が見つかれば同値クラス内の他の値でも同じ欠陥が見つかる、欠陥が見つからない場合は同値クラス内ではその欠陥は見つからないだろう、という考え方で行われるテストで、テストを効率的に実施する代表的な技法のひとつです。
テスト技法2：境界値分析
境界値分析は、判定の境界値に注目して行うテスト技法です。プログラムでは、「＞」と「＝＞」を間違えるというケアレスミスは起こりやすく、このミスが発生しした場合の影響は大です。コードの記述にミスがなかったとしても、仕様の記述にある「以上」「以下」「未満」「より小さい」「より大きい」などの表現が間違って解釈されると、仕様にはない動作をするソフトウェアが作られてしまうことになります。このように境界値には間違いが混入しやすく、境界値をテストすれば、このような間違いがないことが確認できます。
先程の同値分割で示した「未成年」「現役」「高齢者」についての判定式の場合は、
「0」「19」「20」「64」「65」
の5種類を境界値としてテストします。
単体テストの自動化
単体テストが重要であるにもかかわらず、開発工程にかかる負担が大きく、不完全なテストになりやすいことはメリット・デメリットのところでも述べました。その問題を解決する手段のひとつが、単体テストの自動化です。
例えば、継続開発案件をアジャイル体制で開発しているならば、単体テストを自動化してシステムに修正が入るたびに実施することで不具合の早期発見・早期対応が可能になり、手戻りの少ない開発が実現できます。
また、ドライバやスタブの準備を効率化できるツールも存在します。自動化やツールの導入で費用対効果が得られるかはプロダクトの性質によりますが、状況に応じて自動化やツールの導入を検討することも視野に入れると良いでしょう。
さいごに
単体テストは、プロジェクトの成否にかかわるといってもいい重要なテストフェーズです。
バランス良く単体テストを実施することや単体テストを自動化することによって、プロダクトの全体品質の安定的向上していきましょう。
