Junit 4使用要約(五)suite

一、Suiteテスト

Suiteテストは複数のテスト対象クラスをパッケージ化してテストできます.エントリ・テスト・クラスに2つのコメントを追加します.

@RunWith(Suite.class)
@SuiteClasses(TestClass1.class, ...)

このエントリテストクラスを実行すると、フレームワークはパッケージされたすべてのテスト対象クラスをテストします.

import org.junit.runner.RunWith;
import org.junit.runners.Suite;

@RunWith(Suite.class)
@Suite.SuiteClasses({
    TestFeatureLogin.class,
    TestFeatureLogout.class,
    TestFeatureNavigate.class,
    TestFeatureUpdate.class
})

public class FeatureTestSuite {
  // the class remains empty,
  // used only as a holder for the above annotations
}

フレームワークは、テスト対象のクラスを実行し、@Suite.SuiteClassesにリストされた順序でテストを開始します.

二、Parameterizedテスト

多くの場合、多くのテストデータで複数回テストする必要があります.どうしよう?貼り付けコードをコピーして実現しますか?疲れた...
この場合、JUnit 4フレームワークは、Parameterizedテスタ(Runner)を提供し、このようなニーズを実現する.
次の例を見てください.

package mytest;

import static org.junit.Assert.*;

import java.util.Arrays;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;

@RunWith(Parameterized.class)
public class FibonacciTest {
    @Parameters
    public static Iterable<Object[]> data() {
        return Arrays.asList(new Object[][] { { 0, 0 }, { 1, 1 }, { 2, 1 },
                { 3, 2 }, { 4, 3 }, { 5, 5 }, { 6, 8 } });
    }

    private int fInput;

    private int fExpected;

    public FibonacciTest(int input, int expected) {
        fInput= input;
        fExpected= expected;
    }
    @Test
    public void test() {
        assertEquals(fExpected, Fibonacci.compute(fInput));
    }
}

簡単で便利ですね.

・@Parametersで表記し、テストのために用意したデータ

コンストラクタを定義し、コンストラクタのパラメータ順序と準備データの順序が一致する

必要なテスト方法を書く@Test注釈

実行して、データごとにテストする

もし、そのような構造関数を書くのに慣れていない場合は、次の方法を使用することもできます.

@RunWith(Parameterized.class)
public class FibonacciTest {
    @Parameters
    public static Iterable<Object[]> data() {
        return Arrays.asList(new Object[][] { { 0, 0 }, { 1, 1 }, { 2, 2 },
                { 3, 2 }, { 4, 3 }, { 5, 5 }, { 6, 8 } });
    }

    @Parameter(0)
    public int fInput;

    @Parameter(1)
    public int fExpected;

    @Test
    public void test() {
        assertEquals(fExpected, Fibonacci.compute(fInput));
    }
}

運転してみると爽やかではないでしょうか.
おそらく、あなたは完璧主義者で、実行後のエラーメッセージに満足していないかもしれませんが、今エラーを報告したときにフィードバックされた情報はそうかもしれません.

test[3](mytest.FibonacciTest): expected:<2> but was:<0>

エラーを報告したい場合は、テストの入力データを表示します.エラーを報告したい場合は、次のようにします.

test[the 3 test, input:3,2](mytest.FibonacciTest): expected:<2> but was:<0>

これを実現するには簡単ですが、@Parametersパラメータを追加nameコード全体は以下の通りです.

package mytest;

import static org.junit.Assert.*;

import java.util.Arrays;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;

@RunWith(Parameterized.class)
public class FibonacciTest {
    @Parameters(name="the {index} test, input:{0},{1}")
    public static Iterable<Object[]> data() {
        return Arrays.asList(new Object[][] { { 0, 0 }, { 1, 1 }, { 2, 1 },
                { 3, 2 }, { 4, 3 }, { 5, 5 }, { 6, 8 } });
    }

    private int fInput;

    private int fExpected;

    public FibonacciTest(int input, int expected) {
        fInput= input;
        fExpected= expected;
    }
    @Test
    public void test() {
        assertEquals(fExpected, Fibonacci.compute(fInput));
    }
}

ここでは、いくつかのパラメータの意味を少し説明する必要があります.

{index}  ， 
{0}  
{1}  
...
{n}  n+1 

三、Categoriesテスト

1つのテストクラスには多くのテスト対象の方法が含まれています.多くの場合、私たちはこれらのテスト対象の方法を分類し、ある方法をテストする必要があります.では、どうすればいいですか.
次の例を見てください.

public interface FastTests { /* category marker */ }
public interface SlowTests { /* category marker */ }

public class A {
  @Test
  public void a() {
    fail();
  }

  @Category(SlowTests.class)
  @Test
  public void b() {
  }
}

@Category({SlowTests.class, FastTests.class})
public class B {
  @Test
  public void c() {

  }
}

@RunWith(Categories.class)
@IncludeCategory(SlowTests.class)
@SuiteClasses( { A.class, B.class }) // Note that Categories is a kind of Suite
public class SlowTestSuite {
  // Will run A.b and B.c, but not A.a
}

上記の例では、nameとA.bの2つの方法をテストしますが、テストしませんB.c.
次を見てください.

@RunWith(Categories.class)
@IncludeCategory(SlowTests.class)
@ExcludeCategory(FastTests.class)
@SuiteClasses( { A.class, B.class }) // Note that Categories is a kind of Suite
public class SlowTestSuite {
  // Will run A.b, but not A.a or B.c
}

今回は、A.aしか運行しておらず、A.bとA.aは運行していません.

四、Theoriesテスト

いくつかの理論テスト.
まず例を見てみましょう.

@RunWith(Theories.class)
public class UserTest {
    @DataPoint
    public static String GOOD_USERNAME = "optimus";
    @DataPoint
    public static String USERNAME_WITH_SLASH = "optimus/prime";

    @Theory
    public void filenameIncludesUsername(String username) {
        assumeThat(username, not(containsString("/")));
        assertThat(new User(username).configFileName(), containsString(username));
    }
}

少し苦くて分かりにくいのではないでしょうか.大丈夫です.一つ一つ説明します.

B.c教示の枠組みであり、次の試験類は理論試験を行う.

@RunWith(Theories.class)フレームワークに、表示されているデータはすべてテスト用のデータであることを示す.

@DataPoint表記の方法は、理論テストが必要な方法である.

@Theoryテストのデータ(assumeThat表記のデータ)に対して検査を行い、該当するデータは引き続き下へ進み、該当しないデータは無視する.もし、すべてのデータが一致しない場合、@DataPointマークアップのテストは失敗(fail)となります.