3.5 JUnitのassert/failメソッドと例外処理を最大限に利用しよう

JUnit見習が犯しやすい問題として、膨大なtry・catchブロックを使用して、例外を検知して、テストの成否を判定することです。例えば、以下のプログラムです。

 public void exampleTest () {
    try {
       // do some test
    } catch (SomeApplicationException e) {
        fail ("Caught SomeApplicationException exception");
    }
 }

JUnitは自動的に例外を捕まえます。 例外をキャッチせずに「エラー」とすれば、上のような無駄なコードを書かなくてもよくなるわけです。同じことでも、下のコードの方がだいぶすっきりしています。

 public void exampleTest () throws SomeApplicationException 
   {
   // do some test
   }

上の例では、冗長なコードが削除されてシンプルになったため、後からテストプログラムを読んで簡単に理解することができます。また、ソースの保守も簡単です。また、JunitにはたくさんのAssertメソッドが用意されています。それらを使って、よりシンプルでわかりやすいコードを書きましょう。以下のように書く代わりに

assert (creds == 3);

こう書きましょう

assertEquals ("The number of credentials should be 3", 3, creds);　   

上の例はコードを読む人にとっても親切です。そして、Assertが失敗した場合、テストを実行した人により多くのメッセージが表示されます。JUnitはfloatを比較するためのメソッドも用意しています。

assertEquals ("some message", result, expected, delta);

floatを比較する場合、この関数は期待値と結果の差を計算するコードと何度も書かなくても、assertEqualsさえ使用すればよいのです。

assertSameは同じオブジェクトを参照しているかどうか判定するために使用します。assertEqualsは2つのオブジェクトが等しいかどうか判定するために使用します。

3.6 テストはjavadocで書面化しよう

テスト計画をワープロで書くなんて、めんどくさいしミスも多いし大変です。また、ワープロで作った書類は保守も大変です。すぐに実際の単体テストの更新に追いつかず、古臭いものになってしまいます。書類と単体テストのギャップは混乱の元です。可能ならば、テスト計画書をテストクラスのjavadocに盛り込むのがベストでしょう。

3.7 テストはできるだけ小さく、できるだけ早く

全システムのためのテストを実行するのに、数時間もかかっているようではいけません。実際、開発者はもっと簡単にできるテストを継続的に行うべきです。全テストを定期的に走らせることができなければ、システム前提の変更や出来上がりを評価することはできません。エラーは立ち戻りを意味しますし、単体テストのメリットは失われてしまいます。時間のかかる、負荷テストやパフォーマンステストなどは、単体テストの一部として扱わずに別に行いましょう。

(実習課題1）

以下のクラスを作成する

• SQL 6.2の実習課題1の販売管理データベースのaccept_orderテーブルの検索を行うクラスを作成する
• まず、Junitを用いてクラスのテストクラスを作成し、その後に検索クラスを作成する。
• テストのソースなどをみれば、作成したクラスの仕様がわかるように工夫する