単体テスト(たんたいゆにっと)情報システム用語辞典

unit testing / ユニットテスト

» 2011年11月07日 00時00分 公開

 プログラムを構成する最小単位で実行されるソフトウェアテスト(注1)のこと。モジュール(注2)テストともいう。

 伝統的な開発プロセス(注3)においては最初に行われる動的テスト(注4)で、テスト工程の第1段階である。独立して扱える最小単位でテスト対象ソフトウェアを実行し、バグの検出・品質評価・仕様適合性の検証を行う。テストエンジニアやテスターによるテストである。

 XPのプラクティスであるテスト駆動開発ではコーディングに先立って作成したテストコードを使って、プログラムコードをテストすることをいう。これは開発者やプログラマが行うテストで、プログラムの最小単位というより、コーディング作業の1ステップごとに実施するテストといえる。開発者自身がテストを作成−実施する目的は、コーディング対象の仕様を確認−検証することである。

 ソフトウェアは本質的に複雑な存在である。ソフトウェア規模が大きくなると複雑さが指数関数的に増大し、欠陥個所の特定や修正が難しくなるので、より小さな単位で確認や検証を行うことが有効となる。単体テストはこの原理に沿ったものであり、可能な限りの狭い範囲に絞ってテストすることが望ましい。

 テスト工程の単体テストも、テスト駆動開発の単体テストも、出来るだけ早い段階で品質を確保しようとする試みである。バグや誤りを抱えたまま開発プロセスが進行すると誤り部分への作業が行われるので、無駄が増える。また、後工程ではソフトウェアの複雑度が増しているので修正作業がより困難なものとなる。そのため、単体テストは極めて重要な作業とみなされている。

 テスト工程の単体テストはモジュールやコンポーネントなどのソフトウェア部品を1つずつ検査する作業である。テストエンジニアは詳細設計書に基づいてテスト仕様書(テストケース)を作成し、必要に応じてテストドライバテストスタブを用意する。テスターは単体テスト仕様書に則ってテスト対象モジュールを実行し、その結果を記録する。その結果からバグや誤りを判定、必要なバグ修正を行ったうえで、再テストするというサイクルを繰り返す。一般にバグ検出率が一定以下に安定した時点でテスト終了となる。

 その主な目的は、実装が設計仕様どおりになされているかの確認である。バグの検出、品質測定の基礎となる情報の獲得なども目的となる。正常系だけでなく、異常系についてもテストする。このテストで使われるテスト技法は、ブラックボックステストホワイトボックステストに分類して説明されることが多い。後者は単体テスト特有の方法といえる。

 ブラックボックステストは、コードの内部構造を意識せずに入力−出力の対応関係からテストを行う方法である。「同値分割」「境界値分析」「原因結果グラフ技法」「エラー推測」などのテクニックがある。ホワイトボックステストは、コードの内部構造を考慮に入れてテストする方法である。主な技法に「制御パステスト」がある。ほかに「データフローパステスト」「トランザクションフローテスト」などが知られる。

 テスト駆動開発型の単体テストは、コーディングと表裏一体となった開発工程の一部である。その基本サイクルは、まずオブジェクトのインターフェイスに対してテストを書き、次にそのテストを失敗させる実装を行ってテストが失敗することを確認(呼び出されていることを確認)、それから仕様(テスト)を満たす実装を行ってテストを成功させ、最後にコードのリファクタリングを行う――である。このサイクルを繰り返して開発を進めていく。

 これは開発の一部であって、開発者が開発者のための行うものである。このテストで開発者が書くテストケースは具体化された仕様書であって、これに合格することで開発者は自身の作業の正しさを確認できる。また、開発者がテストコードを書く作業を通じて、プログラム構造が可読性が高く整理されたものとなる傾向のある点も利点とされる。

 上述のサイクルはほとんどの場合、xUnitなどのテスティングフレームワークを使った“自動化されたテスト”として行われる。この自動化によってテストコードは随時、成長させながら繰り返し使用するものとなる。例えば、テスト工程でバグが検出され、差し戻し修正を行う場合、そのバグを見つけるテストケースをテストコードに追加する。このテストに合格すれば、デバッグできたことになる(開発者側の手続きとしてである)。これによって回帰テストを効率的に行うことができる。

 同じ「単体テスト」という名前で呼ばれるためにしばしば混乱するが、テスト工程の単体テストとテスト駆動開発型の単体テストは別のものである。これを端的に区別する言葉としてQAテストデベロッパテストがある。ただし、テスト駆動開発型の単体テストで使ったテストコードに、テスト工程でテストエンジニアが品質保証やバグ検出などの視点でテストケースを追加し、開発プロセス全体でテスト自動化を進めるという努力はさまざまな論者によって推奨されている。

 「単体とは何か」についてしばしば議論となるが、これを定義する統一的な標準はない。IEEEなどの規格でも、ソフトウェアを構成する部品の最小単位という抽象的な定義に留まっている。教科書的には、汎用機系の分野ではモジュール、構造化プログラミング言語では関数、オブジェクト指向言語ではクラスもしくはメソッドが単体テストの対象と説明されることが多いが、コンパイルやビルド、リンク、ロードを単体としたり、画面や帳票などの機能が最小単位としたりする場合もある。

 現実には、対象システムのアーキテクチャや設計、およびプロジェクトの管理方針によってさまざまな粒度の単体がある。開発を外部に発注している場合は契約と責任範囲の面から、単体が決定されるかもしれない。現場によっては「機能内単体テスト、機能外単体テスト」「UT01、UT02……」というように複数の粒度を認め、名前を付けて識別しているようだ。特に名付けなどが行われておらず、あいまいなようなら具体的にどのレベルをテストすればいいのかを意識し、必要に応じて確認するとよいだろう。

参考文献

▼『ソフトウェアテスト技法――自動化、品質保証、そしてバグの未然防止のために』 ボーリス・バイザー=著/小野間彰、山浦恒央=訳/日経BP出版センター/1994年2月(『Software Testing Techniques, 2nd Edition』の邦訳)

▼『レガシーコード改善ガイド――保守開発のためのリファクタリング』 マイケル・C・フェザーズ=著/ウルシステムズ=監訳/平澤章、越智典子、稲葉信之、田村友彦、小堀真義=訳/翔泳社/2009年7月(『Working Effectively With Legacy Code』の邦訳)

▼『はじめて学ぶソフトウェアのテスト技法』 リー・コープランド=著/宗雅彦=訳/日経BP社/2005年11月(『A Practitioner's Guide to Software Test Design』の邦訳)

▼『JUnitと単体テスト技法――JUnit4対応』 福島竜=著/ソフト・リサーチ・センター/2006年8月

▼『経験ゼロでもできるプログラミング現場の単体テスト』 片桐一宗=著/翔泳社/2009年5月


Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ