単体テスト導入の第一歩

単体テストの必要性が説かれてからずいぶん時が過ぎたが、今だに導入していないプロジェクトがたくさんある。
xUnit系のフレームワークも、いろいろな目的に利用できるものが簡単に手に入る。単体テストによる品質の向上や開発作業の効率化などの文献や統計もたくさん出ている。これを利用しない手はないと思うんだけどなぁ。
実は、詳細でカバレッジ率の高いテストコードを書かずに簡単なテストコードを記述するだけでも、品質と安定性は格段に向上することになる。その実例を以下に示す。

サンプルコード

StringUtility

public class StringUtility{
    public static boolean isAvailableFileName(String param){
        try{
            return param.endsWith(".zip");
        }catch(NullPointerException e){
            return false;
        }
    }
}

Client

import java.io.File;
public class Client {
    public File createFile(String filename){
        if(!StringUtility.isAvailableFileName(filename)){
            return null;
        }
        return new File(filename);
    }

    public static void main(String[] args) {
        Client client = new Client();
        File file = client.createFile(null);
    }
}

上記の単純なコードを実際に実行してみる。何の問題もなく終了する。

ここで、StringUtilityクラスのisAvailableFileNameメソッドに仕様変更を行う。現在はパラメータがnullの場合、falseを返却している。この例外処理を除外し、nullの場合はStringクラスによって投げられるNullPointerExceptionをそのまま呼び出し元に投げるようにする。

変更後のisAvailableFileNameメソッド

public static boolean isAvailableFileName(String param){
    return param.endsWith(".zip");
}

これにより、StringUtils.isAvailableFileNameメソッドを利用しているすべてのクラスが影響を受けることになる。nullを渡した場合、例外によりプログラムが強制終了してしまう。
上記のような例で一番重要な問題は、「実際にアプリケーションを動かさないと問題が表面化しない。」ということである。
Clientクラスの（従来のチェックシートのような）単体テストが終了しているなら、実際に運用が開始されるか、開発中に偶然発見されるまで問題が表面化しない恐れがある。

さて、実は上記のような問題は簡単に回避することが出来る。単体テストを好きなときに手軽に実行できるように、自動化するのである。そして実際に複雑なテストメソッドを利用しなくても、上記のような異常系の処理をすぐに発見することが可能となる。これは決して大げさではない。

テストを書く

public class LogicTest extends TestCase{
    public void testSetData() throws Exception{
        Logic logic = new Logic();
        logic.setData(new Data("office1", "00-0000-0000"));
    }
}

上記の例では定義されたクラスに対してテストクラスを定義しているが、比較メソッド(assertEquals等)を利用していないが、実際にStringUtilsクラスに変更を行った後にこのテストを実行すると、テストが失敗し、問題をすぐに発見することができる。

• 「サンプルメソッドでNullPointerExceptionを投げるのは設計がダメ」とか、そういうツッコミはダメ。
• 上記の粒度でテスト作って自信満々になるのもダメ。
• テストがまったくないよりはマシ。だけど、このテストで変な自信を持ってしまうのならば、ないほうがマシ。