1. 単体テストとJUnit

この章ではJavaプログラムの単体テストを行うためのツール、JUnitの概要について説明します。

1.1. 単体テスト

システムの品質を保つためには、テストという工程が非常に重要です。テストの目的には、以下の通りです。

• 不具合を発見する
• 仕事が完了したことを確認する
• システムをより優れたものに改良する

バグを発見することは、テストの目的の一つですが、全てではありません。システム開発の一つ一つの工程が、完了したことを、誰でもわかるような明瞭な形で示すために、テストは必要です。また、システムのエンハンスも、テストによりシステムの現在の状態を把握してこそできることです。

テストの一連の工程の中で、まずはじめに行われるのが単体テストです。 単体テストは、作成したコードが要件を満たしているか、確認するためのものです。コードブロック一つ一つは、システムの「部品」とも言えます。「部品」が要件を満たしていなければ、システム全体もうまく動作しません。組み立ててしまってから不具合が見つかった場合、どの「部品」が悪いのか探し当てるには、多くの時間と労力が必要です。

また、不具合発見以外にも、単体テストには、以下の特長があります。

• コードの満たすべき「機能」、プログラムの「設計仕様」を示す
• クラスがいつ「完成」したか、判断基準を与える

コーディングを開始するために、プログラムの「完成像」がどうなるのか、示したものが設計仕様です。設計仕様には、満たすべき機能などをわかりやすい形でまとめています。複数の人が一つのコードを作成、変更、保守することなどを考慮すると、誰にでもわかりやすい、しかも常に最新の状態に保たれた設計仕様をそろえることが重要です。従来は、仕様は「仕様書」としてまとめられていました。しかし、これは、プログラムの保守と同等の労力をドキュメントの保守に費やすことになります。最悪、「設計書は誰かの頭の中にしかない」という場合も少なくありません。

XP (eXtreme Programming) という開発方法論では、設計仕様を単体テストの形で与えることを唱えています。設計時に単体テストを作成し、単体テストをパスする＝完成とするのです。そして、必ず、単体テストとコーディングをセットで行います。単体テストはテストプログラムの形で与えます。プログラムに対する要求が複雑化しているため、人の手によるテストの精度には限界があります。テストプログラムを作成し、自動化テストを行うことが望ましいです。

テストプログラムを書くメリットは、他にもあります。

• 何度でも試せる
  テストプログラムは、一度書いてしまえば、手軽に何度でもテストを行うことができます。
• 使いまわしがきく
  似たような機能のテストを行うとき、テストプログラムのコードを再利用することにより、より短時間にテストを完成させることができます。