今回は、JUnitでの実装をやります。今までは、コードを書き終わったものを記載していましたが、今回はコードを書きながら記載していこうと思います。自分のやり方になりますが。。。

テストクラスの実装方法

仕様確認1

1. koza.csvファイルが存在するときはファイルを読み取り、それをDataクラスに設定し、リストにして返す
2. koza.csvがない場合は、システムエラーを出す

上の仕様を満たす様に、テストケースを考えます。シンプルなもので、単純に実装すれば良さそうです。
「〜そうです。」と記載したのは、実装などはやってみないとわからないこともあるのでこの様に記載しました。早速作ってみます。

テストケースを作る

まずは、単純にテストクラスを作成します。このクラス名は「テスト対象クラスの名前+Test」という形で作成します。
テストクラスと実装するクラスのセットが、そうするとわかりやすいからです。すでに実装していますが「初めから作る」というていで記載します。

作成するクラス

KozaManager(実装クラス)

KozaManagerTest(テストクラス)

＜実装クラス＞

public class KozaManager {

    public Listl fileRead() {
        // 実装前なのでスタブにします。
    }

} 

＜テストクラス＞

public class KozaManagerTest {
    @Test
    public void testFileRead() {
        // これもスタブ
    }
}

現状は、上記の様な状態です。
そして、考えます。何を？。。。仕様の１番目「koza.csvファイルが存在するときはファイルを読み取り、それをDataクラスに設定し、リストにして返す」にはどの様なテストが必要か？を考えます。単純に考えるならば以下の様になります。

1. ファイルの存在を確認する処理が想定通りに動くか？
2. ファイルが存在するならば、それを読み込みデータリストを返却するか？

そして、もう１つの仕様「koza.csvがない場合は、システムエラーを出す」に関しては

1. ファイルが存在しないときはシステムエラーを出し、アプリケーションを終了するか？

それぞれ、上の様なチェック(テスト)を行います。ぶっちゃけて、まずはこの単純な確認を行ってから次に「穴はないか？」を考えれば良いと思います。

なのでシンプルにその様なテストケースを作成します。
まずは。「ファイルの存在を確認する処理が想定通りに動くか？」これを確認するために実装クラスとテストクラスの両方を修正します。着手するのは１つずつなので安心ください。
ますは、テストケース(テストクラス)
＜テストクラス＞

public class KozaManagerTest {
    @Test
    public void testIsFile() {
        // ファイルの存在チェック処理の確認
    }
    // 今はテストしないのでコメントアウト
    // @Test
    public void testFileRead() {
        // これもスタブ
    }
}

とりあえずは、ファイルの存在チェック処理を動かすためのテストケース(メソッド)を作成しました。
ここで、足りないものがあります。

1. テスト対象クラス(実装するクラス)
2. ファイル存在チェック処理メソッド

通常の開発だと、これらを実装してからテストしますが。先に箱(スタブ)だけ作ってしまいます。
＜実装クラス＞

public class KozaManager {
    public boolean isFile() {
        // とりあえずスタブです。
    }
    public Listl fileRead() {
        // 実装前なのでスタブにします。
    }

} 

そして、ちょっと考えてみると「ファイルの存在チェック処理を行うのに、ファイル名が必要だな。。。」と気がつくと思います。

ここが悩みどころ

ファイル名を(引数で)渡す処理方法と、ファイル名を固定して渡す方法のどちらもできるので「どちらの手段が汎用性、保守性共に高いだろうか？」と悩んでみます。
自分の結論は「引数でファイル名を渡す」方が良いと思ったのですが、すでに実装ている部分ではコンストラクタで生成しているので今回は、引数なしでのメソッドにします。なので以下の様なコードになります。
＜実装クラス＞

public class KozaManager {
    /** 作成するファイルが存在するかチェック */
    public boolean isFile() {
        // fileはフィールド変数
        return file.exists();
    }
    public Listl fileRead() {
        // 実装前なのでスタブにします。
    }
} 

＜テストクラス＞

public class KozaManagerTest {
    @Before
    public void initTest() {
        target = new KozaManager();
    }

    @Test
    public void testIsFile() {
        // コンストラクタでファイルが作成されることに注意
        assertTrue(target.isFile("koa.csv"));
    }

    // 今はテストしないのでコメントアウト
    // @Test
    public void testFileRead() {
        // これもスタブ
    }
}

実行結果は下にあります。

でわでわ。。。

今回は、ファイル出力処理を実装します。つまりテストケースの作成と実行を行います。

ファイル出力の実装

ファイル出力と言っても、ファイルの作成自体はすでに実装済みなのでデータをファイルに書き込む処理の実装ということになります。
＜前回までにできていること＞

1. ファイル作成(koza.csv)
2. ファイルの存在チェック(KozaManager#isFile)

ここまでが実装したものになります。ちなみにテストコードは下の様になります。

public class KozaManagerTest {
    /** テスト対象クラス */
    private KozaManager target;

    /**
     *  テストの初期化 
     *  各テスト実行前に起動する
     */
    @Before
    public void initClass() {
        target = new KozaManager();
    }

    /**
     * コンストラクタが起動したかどうかを確認する
     * テストケース
     */
    @Test
    public void testIsInstance() {
        assertNotNull(target);
    }

    /**
     * ファイルの存在チェック処理の確認
     */
    @Test
    public void testIsFile() {
        assertTrue(target.isFile());
    }

    /**
     * ファイルにデータを出力し保存するテストケースです。
     */
    public void testFileCeate() {
        Data data = new Data("名前", "パスワード");
        try {
            target.dataOutput(data);
        } catch(IOException ie) {
            ie.printStackTrace();
            fail();
        }
    }
}

ここでの注意点は、「@Test」のついていないテストケース(メソッド)がファイル出力のテストケースになります。
なので、今回はこのコードを実行しようと思います。
早速「@Test」を上のテストケースにつけます。

/**
 * ファイルにデータを出力し保存するテストケースです。
 */
@Test
public void testFileCeate() {
    Data data = new Data("名前", "パスワード");
    try {
        target.dataOutput(data);
    } catch(IOException ie) {
        ie.printStackTrace();
        fail();
    }
}

想定通りにいかない原因

製造中につきものの「動かない。。。」にあたります。
本当であれば、テストコードの中でファイルの中身を確認するのですが、ファイル出力後のテストケースも考えていないので、とりあえず。。。と言ったところです。
さて、想定通りにいかない原因を考えます。というか探します。本体のコードを見直してみると。。。

public void dataOutput(Data data) throws IOException {
    // おおよそのデータサイズを指定すると余計なメモリを使用しなくて済む
    StringBuilder build = new StringBuilder(50);
    // ヘッダー部分の出力
    build.append(this.createCSVHeader());
    // ファイル出力処理
    write.append(build.toString());
    // StringBuilderのクリア
    build.setLength(0);

    // データ部分の出力
    build.append(data.getName() + ",");
    build.append(data.getPassword());
}

「あー、これはファイルの中身がなくて当然だなぁ」と気がつきます(笑)
上のコードでは、出力用文字列作成用のオブエジェクトを作成しているだけです。

build.append(data.getName() + ",");
build.append(data.getPassword());

なので修正します。

public void dataOutput(Data data) throws IOException {
    // おおよそのデータサイズを指定すると余計なメモリを使用しなくて済む
    StringBuilder build = new StringBuilder(50);
    // ヘッダー部分の出力
    build.append(this.createCSVHeader());
    // ファイル書き込み処理
    write.write(build.toString());
    // StringBuilderのクリア
    build.setLength(0);

    // データ部分の書き込み
    build.append(data.getName() + ",");
    build.append(data.getPassword());
    write.write(build.toString());
}

そして、ファイルに出力したらファイルの入出力で使用しているReaderとWriter、そのほかのフィールド変数の後始末をする必要があります。出ないとメモリ上にインスタンスが残ってしまいます。Javaの場合はガベージコレクションで最終的にメモリは解放されますが、ここでは明示的に「KozaManger」クラスのインスタンスが解放されるときに各フィールドの解放を行います。(デストラクタに実装)

/**　デストラクタ */
@Override
protected void finalize() throws Throwable {
    // フィールド変数の後始末
    file = null;
    read.close();
    write.close();
    write = null;
    read = null;
}

それでは、改めてテストを実行してみます。しかし想定通りに行きませんでした。。。
ファイルは出力しているのですが、肝心の中身が出力されていない状態でした。
原因としては「ファイルを閉じていない」と「ファイルを開くときに追記モードで開いていない」ことでした。
そして、最終的には以下の様なコードになりました。

public void dataOutput(Data data) throws IOException {
    if (file.canWrite() == false) {
        throw new IOException("ファイルの書き込みができません: " + file.getAbsolutePath());
    }
    // おおよそのデータサイズを指定すると余計なメモリを使用しなくて済む
    StringBuilder build = new StringBuilder(50);
    // ヘッダー部分の出力
    build.append(this.createCSVHeader());
    // ファイル書き込み処理
    write.write(build.toString());
    write.newLine();
    // StringBuilderのクリア
    build.setLength(0);
    // データ部分の書き込み
    build.append(data.getName() + ",");
    build.append(data.getPassword());
    write.write(build.toString());
    write.newLine();
    write.close();
}

というわけで、テストをしながら実装するのでやりやすい(色々と試しやすい)実装方法だと思います。
ちなみにテストケースは、色々と試したので少々変わっています。

@Test
public void testFileCeate() {
    Data data = new Data("test", "passwd");
    try {
        target.dataOutput(data);
    } catch(IOException ie) {
        ie.printStackTrace();
        fail("ファイル入出力に問題があります。");
    } catch(Exception e) {
        e.printStackTrace();
        fail("想定外のエラーが起きました。");
    }
}

そして、本体のクラス(メソッド)も同様に修正が入っております。最終的に以下の様な実装になりました。

public void dataOutput(Data data) throws IOException {
    if (file.canWrite() == false) {
        throw new IOException("ファイルの書き込みができません: " + file.getAbsolutePath());
    }
    // おおよそのデータサイズを指定すると余計なメモリを使用しなくて済む
    StringBuilder build = new StringBuilder(50);
    // ヘッダー部分の出力
    build.append(this.createCSVHeader());
    // ファイル書き込み処理
    write.write(build.toString());
    write.newLine();
    // StringBuilderのクリア
    build.setLength(0);
    // データ部分の書き込み
    build.append(data.getName() + ",");
    build.append(data.getPassword());
    write.write(build.toString());
    write.newLine();
    write.close();
}

後、ファイルを開くときに追加書き込みモードで開く必要があるので。。。(今回の実装ではデータの保存を行うのでフィールドで保持する必要があるため)コンストラクタの修正も行いました。

// 修正前のコード
write = new BufferedWriter(new FileWriter(file));
// 修正後のコード
write = new BufferedWriter(new FileWriter(file, true));

実行結果は以下の通りです。

次回は、各処理を(ファイル存在チェック〜ファイル出力)テストします。最終的な確認のコードです。

でわでわ。。。