n-3104の備忘録
JUnit
最終更新:
Bot(ページ名リンク)
-
view
JUnit4
4からはアノテーションが使えてすっきりする。
- POJOとして作成できる(TestCaseの継承が不要)。
- テストメソッド名に「test」プレフィックスが不要。その代わり@Testアノテーションを付ける。
- assertはorg.junit.Assertをstaticインポート。Eclipseのウィザードでクラスを作ると入れておいてくれる。
- @Ignoreを利用すると、そのメソッドについてはテストしないように出来る。作成中のテストメソッドに使うと便利。
- 3までは junit.framework.- パッケージを利用したが、4からは org.junit.- を利用する。
- @Parametersを使うことで、テストデータとテストデータの組み合わせの数だけテストを実行することが出来る。
- @Test(timeout = 1000)とすることで、テストに掛かる時間にタイムアウトを設けられる。パフォーマンスが重要な処理などで利用できそう。
参考サイト
|http://www.okisoft.co.jp/esc/testing/JUnit4-TestNG.html|4の使い方について丁寧に説明しているサイト。
|http://www.devx.com/Java/Article/31983+codeitemarea|JUnitのサイトで紹介されている4の解説サイト。英語だがサンプルコードもあり、概要がよく整理されている。@Parametersの例もある。
|http://www.junit.org/taxonomy/term/12|JUnitのホームページのArticlesのページ。他にも色々リンクがあり、例えばMockオブジェクトの利用法に関するリンクなどもある。
|http://www.okisoft.co.jp/esc/testing/JUnit4-TestNG.html|4の使い方について丁寧に説明しているサイト。
|http://www.devx.com/Java/Article/31983+codeitemarea|JUnitのサイトで紹介されている4の解説サイト。英語だがサンプルコードもあり、概要がよく整理されている。@Parametersの例もある。
|http://www.junit.org/taxonomy/term/12|JUnitのホームページのArticlesのページ。他にも色々リンクがあり、例えばMockオブジェクトの利用法に関するリンクなどもある。
Mockオブジェクトの利用
バグがないプログラムのつくり方|http://www.amazon.co.jp/gp/product/479810714X/に記述があったが、Mockオブジェクトはテストクラスのインナークラスとすると管理がしやすいし、Mockオブジェクト内でassertを行ったり、クラスが呼ばれたかどうかを調べることも出来る。
具体的には、以下のようにHogeとFugaがあった際に、FugaのMockを作ることで以下のテストが出来る。
具体的には、以下のようにHogeとFugaがあった際に、FugaのMockを作ることで以下のテストが出来る。
- Hogeが追加された全てのFugaのfugafugaメソッドを実行しているか。HogeTestのcountフィールドを利用して確認している。
- HogeがFugaのfugafugaメソッドを呼び出す際に正しくプレフィックスやサフィックスを追加しているか。HogeMock内のassertEqualsで確認している。
しかし、インナークラスにこんな使い方があるとは、勉強になる。
import java.util.ArrayList;
import java.util.List;
public class Hoge {
List<Fuga> list = new ArrayList<Fuga>();
public void hogehoge(String message) {
for (int i = 0; i < list.size(); i++) {
Fuga fuga = list.get(i);
fuga.fugafuga("+++" + message + "+++");
}
}
public void addFuga(Fuga fuga) {
list.add(fuga);
}
}
public interface Fuga {
void fugafuga(String message);
}
import static org.junit.Assert.assertEquals;
import org.junit.Test;
public class HogeTest {
// HogeによってFugaのfugafugaメソッドが呼ばれた回数
private int count;
private class FugaMock implements Fuga {
public void fugafuga(String message) {
// HogeがFugaのfugafugaを呼び出す際に、プレフィックスとサフィックスを
// 正しく追加できているかを確認
assertEquals("+++Hello*+++", message);
// HogeがFugaのfugafugaメソッドを実行した回数を確認するためインクリメント
count++;
}
}
protected void setUp() {
this.count = 0;
}
@Test
public void testHogehoge() {
Hoge hoge = new Hoge();
hoge.addFuga(new FugaMock());
hoge.addFuga(new FugaMock());
hoge.hogehoge("Hello*");
assertEquals(2, this.count);
}
}
ソースの配置フォルダとパッケージ
バグがないプログラムのつくり方|http://www.amazon.co.jp/gp/product/479810714X/によると、テスト対象のソースと同一パッケージの同一フォルダが良いらしい。理由としては、別フォルダにするとテストクラスの作り忘れが起きやすいからだそうだ。確かにそんな気もするので、今後は同一フォルダに入れるようにしよう。
個人的には、パッケージは同じでもソースフォルダは別にした方が、テストクラス用のユーティリティクラスを作った際などに分かりやすくてよい気もするんだけど。この辺はプロジェクトの規模とメンバーのレベルによるのかな。
個人的には、パッケージは同じでもソースフォルダは別にした方が、テストクラス用のユーティリティクラスを作った際などに分かりやすくてよい気もするんだけど。この辺はプロジェクトの規模とメンバーのレベルによるのかな。