3. テストクラス2

2章ではテストクラスの基本的な作成方法について説明しました。本章では、テストクラス作成時の注意点について説明します。以下は、"http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html"より抜粋したものです。

3.1 テストメソッドが処理される順序に注意しよう

　一つのテストクラスの中のメソッドは、上から順番に実行されるわけではありません。ですから、上のテスト結果を前提としたテストメソッドなど、記述してはいけません。
例えば、データベースへの追加、削除を行うクラスのテストを行うとします。テストクラスを以下のように記述したとします。

 public class TestSample extends TestCase{
    ...      
    
    public void testInsert(){
         //テスト用のデータを挿入する
 　　}
    public void testDelete(){
         //挿入したデータを削除する
	　　}
      ...
  
 }

上の例では、testDeleteメソッドは、testInsertメソッドの後に実行されることを前提に記述されています。しかし、テストメソッドは「testInsert →　testDelete」の順に実行されるとは限りません。testDeleteが先に実行された場合、このテストは失敗します。このような場合、失敗の原因追及をするのは非常に難しいですし、結果的にテストクラスに問題があるわけですから、本末転倒ともいえます。

3.2 「副作用」があるテストは書かない

テストを行うとデータベースが更新されるなど、システムの状態を更新する「副作用」のあるテストには問題が2点あります。

まず、他のテストケースが依存しているデータに影響を及ぼすということです。

データなど変更された場合、個々のテストは正しく実行されるかもしれませんが、全てのテストケースを「テストスイート」にまとめたとき、他の単体テストは失敗する可能性があります。失敗の原因を追求するのは難しいです。しかも、このようなエラーは本来検知したい「エラー」とはかけ離れています。

二つ目が、手動で調整しないとテストを繰り返し行うことができない、ということです。

データベースよりデータを消すなど、テストケースがシステムの状態を更新する場合、手動で調整しない限り、テストを繰り返し行うことができません。「誰でも利用できる」テストにするためには、テストプログラムの他に調整の手順を記述した「手順書」が必要です。それに加え、テストを自動で行うことができません。そのため、テストを自動で走らせることができなくなり、作業効率が落ちます。

3.3 テストはソースコードと同じ場所に保管しよう

テストのソースとクラスを同じ場所に保管すれば、テストとクラスを同時にコンパイルすることができます。これで、開発中テストとクラスを常に対応させた状態で更新し続けることができます。実際、単体テストは、ビルド作業とセットで行うべきです。でないと、テストがすぐ時代遅れで無意味なものになってしまいます。

3.4 テストには、適切な名前を付けよう

テストケースの名前は Test(クラスの名前)（テストを行う機能）としましょう。例えば、MessageLogクラスのためのテストクラスの名前は、TestMessageLogとなります。こうすれば、テストがどのクラスをテストするためのものなのか、一目でわかります。

また、テストメソッドの名前も、「何をテストしているのか」よくわかるように付けましょう。例えば、以下のようにです。

testLoggingEmptyMessage()
testLoggingNullMessage()
testLoggingWarningMessage()
testLoggingErrorMessage()

適切なネーミングがされていれば、後からコードを読む人もテストの目的をすばやく理解することができます。.