パンドラの小箱を開いてしまった。もう後戻りはできない。地上には「絶望」が満ちあふれてしまった。そうである。あらゆるテストケースを想定し、テストすることは非現実的である。では、どのようなテストをどのようにすればよいのだろうか・・・・・

さて、「ユースケースシナリオはテスト仕様書であるべきだ。『ユースケースもテストすべきである』」。これは監修者の持論である。そして、「シナリオに制約的記述を盛り込み、表明でホワイトボックステストする」というのが、理想像であった。Java 1.4に表明が導入されたことで、理想が現実のものとなり、本書をここに上梓する。

「ユースケースをテストする」というと違和感があるかもしれない。しかし、レビューというマジックワードでごまかしてきてはいなかっただろうか。レビューに具体的な検証項目があったであろうか。単に文言のチェックに終わってはいなかったであろうか。テストという用語はプログラムを対象として使用されることが多い。レビューという用語は仕様書や設計書などの文書に対して使われてきた帰来がある。本書では、レビューをテストと置き換え、文書もテストする。「詳細設計をテストする」となる。しかし、詳細設計の前段階である、基本設計の品質が悪ければ、詳細設計の品質を向上させても意味がない。

そして、テスト工程と仕様化工程が十分に連携していない、もしくは仕様を検証していないことによって、ソフトウェアの信頼性や開発時の生産性を低下させている。したがって、基本設計、つまりユースケースからテストする必要が出てくる。ユースケースのテスト（レビューではない）にパスしていないのに下流のテストを強化しても意味がないのである。本書では、レビューをテストと置き換えるだけでなく、テストファーストを単にプログラミングの前にテストコーディングすることから、設計の前にテスト仕様を作成するということに昇華させた。このことによって、運用テスト、結合テスト、単体テストを連携でき、品質を向上させることができる。

ところで、XP（エクストリームプログラミング）のブームにより、テストファーストの重要性が認知され始められて、JUnitなどのテストツールの解説書が出回りだした。しかし、肝心のテストケースの作成についてはないがしろにされている。JUnitの文献などでは、正常処理と異常処理の一連のケースをテストせずに、単にひとつの正常値だけでテストしているものさえある。これも正常値か偶然動作したのかさえ区別していない。ましてや、Java 1.4から導入された表明も使いこなせていないのが実情である。

そこで、本書では、テストファーストではあまり言及されていない、テストケースの作成にも注力した。さらに、表明（契約の設計）を適用し、より高品質ソフトウェアの開発を目指した。ホワイトボックステストのためにIF文や例外を大量に書き、かえって保守性を低下させているならば、ぜひ、本書を読み、表明を取り入れてみてほしい。

なお、本書を書くに当たって、project_iの皆さん、特に友枝氏、高安氏には非常に有益なアドバイスを頂いた。ここに感謝の意を表する。本書がテストの「希望」の光となれば幸いである。


本書の内容
第1章「テスト、テスト、テスト」では、テストの重要性について述べ、テストをする上でXP(eXtreme Programming)のテストファーストのプラクティスが有効であること、テスト時のプラクティスについて述べる。

第2章「テストツール」では、テストファーストをJavaで実現するJUnitのフレームワーク、JUnitを実行するテストランナ、さらにテストを自動化するAntとMavenを使ったテストについて述べる。IDE(Eclipse)からJUnit、Mavenを連携する方法についても触れる。

第3章「テストの実行」では、エラーの種類とテストの種類を概説し、テスト工程と仕様化工程を連携させるためにV字モデルにマッピングさせている。とくに、ユースケースからDT（デシジョンテーブル；決定表）を用いてテストケースを抽出し、ブレークダウンさせながら連携させている。また、契約による設計についてもふれる。

第4章「単体テストの周辺」では、外部リソース、未完のクラスやメソッドに依存している場合など単体でテストできない場合に対応するため、モックオブジェクトおよびボックスメタファによるテストについて述べる。また、データベースアクセスのテスト(DBUnit)、ユーザインタフェースのテスト(Cactus,ServletUnit,HttpUnit,StrutsTestCase,JSPUnit,Solex)、ログの活用(Log4J)についてもふれる。

第5章「テストの管理」では、テストケースを含むテストクラスの版管理、バージョン管理について開発と運用の側面から述べる。EclipseでのCVSの扱い、CruiseControl、Alexandria、Gump、XPlannerの使い方についても概説する。

第6章「まとめ」では、本書の主題ではなかった、検収テスト、パフォーマンステストについて概説する。パフォーマンステストのツールである、JMeter、Watchdogの使い方についても概説する。


付録−A　JUnitタグ
AntとJUnitとを連携させるためにbuild.xmlに記述する<junit>タグと、テスト結果をXMLやHTMLで出力させる<junitreport>タグについて述べます。

付録−B　インストレーション手順
Ant、Cactus 、CruiseControl 、CVS、DBUnit、Eclipse、HttpUnit 、JMeter、JUnit、Maven、MySQL、ServletUnit 、Solex、Struts 、StrutsTestCase、Tomcat、Xplanner、Watchdogのインストレーションに説明します。

付録−C Strutsバリデータ
Struts 1.1から導入されてバリデータ（Validator）と呼ばれる、検証機能について詳述します

本書の対象読者
Java、およびJ2EEによるシステムの設計／実装している（あるいはしようとしている）開発者、および管理者を対象としている。また、テストケースの作成に関しては、あらゆる開発や管理者にも読んでいただきたい。なお、本書は、JavaやJ2EEの入門書ではないため、これらについては詳述しない。テスト全般についても他書を当たってほしい。また、開発プロセスもUPやXPなど特定のプロセスを前提とはしていないために特段の前提知識は不要である。一部、UMLも使用しているがこちらも前提知識がなくても内容は理解できるはずである。

本書の特徴
テストファーストのメリットを述べ、それをJavaで実現するツールであるJUnitを中心に単体テストに焦点をあてて、無駄なく漏れの少ないテストケースの作り方から、より信頼性の高いソフトウェアを開発できる表明を利用したテストまで解説している。単にJUnitなどのツールの解説にとどまらず、システム開発全般における、単体テストという位置づけで、テストケースの作成から、表明によるテストまで、単体テストに関してを網羅的に述べている。このためユースケースのレビュー方法から、テストクラスの管理まで具体的に言及している。さらに単体でテストできない場合についても言及している。このため、テストファーストの実践ガイドとして利用できるだけでなく、オブジェクト指向開発、さらに従来型開発のためのテストの実践ガイドとして利用できる。とくに開発フェーズ名は、取り組み易いように従来型の開発で利用される名称にした。単に仕様書のテスト方法を習得して頂くだけでも有益であろう。