JUnitテストプログラミング¶

目次
JUnitテストプログラミング

JUnitテスト環境¶

NetBeans IDEでは、ユニットテストツールの1つとしてJUnitを選択することができます。

ステップバイステップでテストケースの記述¶

JUnitでテストケースを作成する例を、単純なものから徐々に機能を付け足して見ていきます。

最小限のテストケース¶

まずは、最小限のテストケースを記述したサンプルです。

ソースコードを表示隠す

package com.example.foo;  // (1)

import org.junit.Test;
import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.*;

public class FooTest {       // (1)
    Foo sut = new Foo(123);  // (2)

    @Test
    public void idが123を返却する() {       // (3)
        assertThat(sut.getId(), is(123));   // (4)
    }

}

ポイント

(1) テスト対象クラスFooと同じパッケージでテストケースクラスFooTestを定義します。
(2) フィールドsut¹にテスト対象クラスのインスタンスを保持します。
(3) テストメソッドは@Testアノテーションを付与し、戻り値void、引数なし、テスト内容を表す日本語のメソッド名²で定義します。
(4) テスト結果の判定は、assertThat文などのassert系メソッドを使用し、実行結果と期待値を引数に渡します。

¹ テスト対象とするシステムをSystem Under Testと呼ぶのでその頭辞語sutをフィールド名とします。
fn2. テストケース一覧表のテストケース名をそのままメソッド名にすると対応が容易です。

テストの初期化、後始末処理を記述¶

複数のテストメソッドを実行するにあたって、共通の初期化処理、後始末処理がある場合、各テストメソッドに同じ処理を書くのはDRY原則を踏みにじるので、@Before、@Afterアノテーションをつけたメソッドに一本化します。

ソースコードを表示隠す

package com.example.foo;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.*;

public class FooTest {
    Foo sut;

    @Before
    public void setUp() {       // (1)
        sut = new Foo(123);
        sut.init();
    }

    @After
    public void tearDown() {    // (2)
        sut.release();
    }

    @Test
    public void idが123を返却する() {
        assertThat(sut.getId(), is(123));
    }

}

ポイント

(1) テストメソッド実行前に呼ばれるsetUp¹メソッドを@Beforeアノテーションを付与して定義します。
(2) テストメソッド実行後に呼ばれるtearDown²メソッドを@Afterアノテーションを付与して定義します。リソースの解放が必要なテスト対象クラスなどの場合に有用です。

¹ JUnit 3時代のメソッド名setUpを習慣で使い続けているもので、別な名前を使ってもかまいません。

² 注釈1と同様です。

一連のテストケース実行前後に一度だけ初期化、後始末処理を記述¶

一連のテストメソッドを実行する前に一度だけ初期化処理を実行し、一連のテストメソッドを実行した後に一度だけ後始末処理を実行したい場合、@BeforeClass、@AfterClassアノテーションをつけたメソッドを記述します。

ソースコードを表示隠す

package com.example.foo;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;
import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.*;

public class FooTest {
    Foo sut = new Foo(123);

    @BeforeClass
    public static void setUpClass() {       // (1)
        Foo.initialize();
    }

    @AfterClass
    public static void tearDownClass() {    // (2)
        Foo.shutdown();
    }

    @Test
    public void idが123を返却する() {
        assertThat(sut.getId(), is(123));
    }

}

ポイント

(1) 一連のテスト実行前に一度だけ呼ばれるメソッド(setUpClass)を@BeforeClassアノテーションを付与して定義します。ライブラリの初期化など一度だけ実行する場合に有用です。
(2) テストメソッド実行後に呼ばれるメソッド(tearDown)を@AfterClassアノテーションを付与して定義します。ライブラリの後始末など一度だけ実行する場合に有用です。

異常系のテストで例外がスローされた場合に成功と判定したい¶

異常値を入力して例外がスローされることをテストで確認したい場合の記述例です。

ソースコード断片を表示隠す

    @Test(expected = IllegalArgumentException.class)
    public void countに負の値を渡して例外がスローされること() {
        sut.count(-1);
    }

ポイント

@Testアノテーションに、expected属性で例外クラスを指定します。

応用

スローされる例外の型だけでなく、メッセージまで識別したい場合、ExpectedExceptionを使う
Ruleを使う？

テストのグルーピング¶

テストランナーEnclosed.classを使って、ネストクラスごとにテストを実行します。
ネストクラスごとに@Beforeなどで初期化を行うことができます。

ソースコードを表示隠す

package foo;

import org.junit.Before;
import org.junit.Test;
import org.junit.experimental.runners.Enclosed;
import org.junit.runner.RunWith;
import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.*;

@RunWith(Enclosed.class)
public class FooTest {

    public static class 正の場合 {
        Foo sut;

        @Before
        public void setUp() {
            sut = new Foo(1);
        }

        @Test
        public void nextを呼ぶと5が返却される() {
            assertThat(sut.next(), is(5));
        }
    }

    public static class 負の場合 {
        Foo sut;

        @Before
        public void setUp() {
            sut = new Foo(-1);
        }

        @Test
        public void nextを呼ぶと-5が返却される() {
            assertThat(sut.next(), is(-5);
        }
    }

}

注意点¶

外側のクラスに@RunWith(Enclosed.class)を指定し、かつ内部クラスに@RunWith(Enclosed.class)を指定するとテストメソッドが実行されません。
内部クラスと同レベルでテストメソッドを定義してもテストメソッドは実行されません。

同じテストメソッドに複数のデータを入力してテストを実行する¶

いくつか手段があります。

テストランナーParameterizedを使う
テストランナーTheoriesを使う

歴史的経緯で最初にParameterizedが導入され、その後Theoriesが導入されました。今ではTheoriesを使うのがいいようです。

テストランナーTheoriesと、@DataPointおよび@DataPointsアノテーションを使用¶

テストメソッドは引数を取るように定義
2つ以上の引数を定義した場合、総当りの組み合わせで引数に値が入る

テストランナーTheoriesと、@TestedOnアノテーションを使用¶

テストメソッドに引数を設け、引数に@TestedOnアノテーションで複数の値を記述します。
その値ごとにテストメソッドを呼び出します。
上述の@DataPointsをテストメソッドにインラインで定義するようなイメージです。

ソースコードを表示隠す

package com.example.foo;

import org.junit.experimental.theories.Theories;
import org.junit.experimental.theories.Theory;
import org.junit.experimental.theories.suppliers.TestedOn;
import org.junit.runner.RunWith;
import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.*;

@RunWith(Theories.class)
public class FooTest {
    Foo sut = new Foo(123);

    @Theory
    public void doublerの確認(@TestedOn(ints = {1, 2, 3, 4}) int in) {
        assertThat(sut.double(in), is(in * 2));
    }
}

2つ以上の引数を定義した場合、総当りの組み合わせで引数に値が入る
TestedOnアノテーションはVer.4.10現在でint[]型の属性intsのみ定義されている
- 他の型をテストメソッド引数で扱いたい場合は、自前でアノテーションとParameterSupplierのサブタイプとを定義する

テストランナーTheoriesと、入力値・期待値の組み合わせを保持するTextureクラスの定義¶

入力値、期待値を、別々のフィールドで@DataPointsで定義し、テストメソッドの引数2つで入力値と期待値を受け取ると、本来の入力値ー期待値の組み合わせではなく、総当りで引数に値が入れられてしまいます。
そこで、一つの入力値ー期待値の組を保持するFixtureクラスを定義し、@DataPointsではFixtureクラスの配列を定義します。
テストメソッドの引数は、Fixture型を1つ取るようにします。

ソースコードを表示隠す

package com.example.foo;

import org.junit.experimental.theories.DataPoints;
import org.junit.experimental.theories.Theories;
import org.junit.experimental.theories.Theory;
import org.junit.runner.RunWith;
import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.*;

@RunWith(Theories.class)
public class FooTest {

    static class Fixture {
        int input;
        int expected;

        Fixture(int input, int expected) {
            this.input = input;
            this.expected = expexted;
        }
    }

    Foo sut = new Foo(123);

    @DataPoints
    public static Fixture[] FIXTURES = {
        new Fixture(1, 2),
        new Fixture(2, 6),
        new Fixture(3, 12),
        new Fixture(4, 20),
        new Fixture(5, 30)
    };

    @Theory
    public void 計算値を返却する(Fixture fixture) {
        assertThat(sut.calc(fixture.input), is(fixture.expected));
    }

}

テストケース記述のあれこれ¶

テストメソッドを記述する単位¶

最小単位でテストメソッドを記述する¶

1つのメソッドでは1つのassert文という意見もありますが、テストの意味が1つであれば複数のassert文があってもよいと考えます。
逆に、意味が複数になるのであれば、メソッドを分けて書くのがいいです。
意味が複数であれば、バグがそれぞれに起因して別々に発生するので、バグの絞込みも容易になり、テスト記述内容も明瞭になります。

2つの意味を1つのメソッドに書いた例を表示隠す

    @Test
    public void 整数値の格納() {
        sut.setValue(Integer.MAX_VALUE); // 正の整数
        assertThat(sut.isPositive(), is(true));
        sut.setValue(Integer.MIN_VALUE); // 負の整数
        assertThat(sut.isPositive(), is(false));
    }

2つの意味を2つのメソッドにそれぞれ書いた例を表示隠す

    @Test
    public void 正の整数値を格納() {
        sut.setValue(Integer.MAX_VALUE);
        assertThat(sut.isPositive(), is(true));
    }

    @Test
    public void 負の整数値を格納() {
        sut.setValue(Integer.MIN_VALUE);
        assertThat(sut.isPositive(), is(false));
    }

期待値と結果の照合¶

文字列の照合¶

文字列が完全一致¶

    @Test
    public void 同一名である() {
        sut.setName("Thomas");
        assertThat(sut.getName(), is("Thomas"));
    }

org.hamcrest.CoreMatchers.isは、等価判定なので文字列の場合 String#equalsTo と同じ判定となります。

大文字小文字を無視して一致¶

インスタンス（参照先）が一致¶

org.hamcrest.CoreMatchers.sameInstance を追記します。

    @Test
    public void 同一の属性インスタンスが取得できる() {
        sut.setAttributes(attribute);
        assertThat(sut.getAttributes(), is(sameInstance(attribute));
    }

真偽の一致¶

    @Test
    public void 真となる() {
        assertThat(sut.isPrimary(), is(true));
    }

    @Test
    public void 偽となる() {
        assertThat(sut.isSecondary(), is(not(true)));
    }

ほぼ10年前に更新

ファイル (0)

プロジェクト

全般

プロフィール

ソフトウェアエンジニアリング

最近更新されたページ¶

タグクラウド¶

タグ¶

Wiki

JUnitテストプログラミング¶

JUnitテスト環境¶

ステップバイステップでテストケースの記述¶

最小限のテストケース¶

テストの初期化、後始末処理を記述¶

一連のテストケース実行前後に一度だけ初期化、後始末処理を記述¶

異常系のテストで例外がスローされた場合に成功と判定したい¶

テストのグルーピング¶

注意点¶

同じテストメソッドに複数のデータを入力してテストを実行する¶

テストランナーTheoriesと、@DataPointおよび@DataPointsアノテーションを使用¶

テストランナーTheoriesと、@TestedOnアノテーションを使用¶

テストランナーTheoriesと、入力値・期待値の組み合わせを保持するTextureクラスの定義¶

テストケース記述のあれこれ¶

テストメソッドを記述する単位¶

最小単位でテストメソッドを記述する¶

期待値と結果の照合¶

文字列の照合¶

文字列が完全一致¶

大文字小文字を無視して一致¶

インスタンス（参照先）が一致¶

真偽の一致¶