JUnit入門(5) - JUnit5の拡張(Extension)

前回の続き

JUnitの Extension インターフェース

JUnit4のRunnerと同様、JUnit5も拡張をすることができる。

JUnit5が提供している 拡張インターフェース(Extension を継承したインターフェース)は次のとおり。

• ContainerExecutionCondition
  • メソッド - evaluate(ContainerExtensionContext)
    • 戻り値の型 - ConditionEvaluationResult
  • テストクラスレベルで実行可否の判断する
• TestExecutionCondition
  • メソッド - evaluate(TestExtensionContext)
    • 戻り値の型 - ConditionEvaluationResult
  • テストメソッドの実行可否の判断する
• BeforeAllCallback
  • メソッド - beforeAll(ContainerExtensionContext)
    • 戻り値の型 - void
  • @BeforeAll の前に実行される
• BeforeEachCallback
  • メソッド - beforeEach(TestExtensionContext)
    • 戻り値の型 - void
  • @BeforeEach の前に実行される
• BeforeTestExecutionCallback
  • メソッド - beforeTestExecution(TestExtensionContext)
    • 戻り値の型 - void
  • テスト(@Test)の前に実行される
• AfterTestExecutionCallback
  • メソッド - afterTestExecution(TestExtensionContext)
    • 戻り値の型 - void
  • テスト(@Test)の後に実行される
• AfterEachCallback
  • メソッド - afterEach(TestExtensionContext)
    • 戻り値の型 - void
  • @AfterEach` の後に実行される
• AfterAllCallback
  • メソッド - afterAll(ContainerExtensionContext)
    • 戻り値の型 - void
  • @AfterAll の後に実行される
• TestInstancePostProcessor
  • メソッド - postProcessTestInstance(Object, ExtensionContext)
    • 戻り値の型 - void
  • テストクラスのインスタンス生成後に実行される
• TestExecutionExceptionHandler
  • メソッド - handleTestExecutionException(TestExtensionContext, Throwable)
    • 戻り値の型 - void
  • テスト時に発生した例外の扱いを決定する
• ParameterResolver
  • メソッド - supports(ParameterContext, ExtensionContext)
    • 戻り値の型 - boolean
  • メソッド - resolve(ParameterContext, ExtensionContext)
    • 戻り値の型 - Object
  • テストメソッドに与える引数を解決する

---

テストライフサイクル

これらの Extension は次の順番でテストクラスの生成、テストの実行、テスト終了までの一連の流れに組み込まれる。

1. ContainerExecutionCondition
2. BeforeAllCallback
3. テストクラスの @BeforeAll
4. テストクラスのインスタンス生成
5. TestInstancePostProcessor

ここから、テストがある場合

1. TestExecutionCondition
2. BeforeEachCallback
3. テストクラスの @BeforeEach
4. BeforeTestExecutionCallback
5. ParameterResolver#supports(引数の数だけ)
6. ParameterResolver#resolve(引数の数だけ)
7. テストクラスの @Test(テスト)
8. TestExecutionExceptionHandler(テスト中に例外が発生した場合だけ)
9. AfterTestExecutionCallback
10. テストクラスの @AfterEach
11. AfterEachCallback

ここから、同じクラスに他のテストがある場合

1. 次のテストのインスタンス生成
2. TestInstancePostProcessor
3. TestExecutionCondition
4. ...
5. AfterEachCallback

ここから、ネストしたクラスがある場合

1. ContainerExecutionCondition
2. BeforeAllCallback
3. アウタークラスのインスタンス生成
4. TestInstancePostProcessor
5. インナークラスのインスタンス生成
6. TestInstancePostProcessor
7. TestExecutionCondition
8. BeforeEachCallback
9. アウタークラスの @BeforeEach
10. インナークラスの @BeforeEach
11. BeforeTestExecutionCallback
12. ParameterResolver#supports(引数の数だけ)
13. ParameterResolver#resolve(引数の数だけ)
14. テストクラスの @Test(テスト)
15. TestExecutionExceptionHandler(テスト中に例外が発生した場合だけ)
16. AfterTestExecutionCallback
17. インナークラスの @AfterEach
18. アウタークラスの @AfterEach
19. AfterEachCallback

ここから、インナークラスにテストがない場合

1. AfterAllCallback

ここから、他にテストがない場合

1. テストクラスの @AfterAll
2. AfterAllCallback

確認コードはこちらにある、 NestedClasses.java/NoTest.java/TestLifecycleCallbacks.java を参照。

github.com

---

Extension の登録

実装した Extension は @ExtendWith アノテーションをクラスまたはメソッドに指定することによって登録できる。

@ExtendWith({ FooExtension.class, BarExtension.class })
public class FooTest {
  @Test
  @ExtendWith(BazExtension.class)
  void qux() {}
}

なお、残念なことにjunit-jupiter-apiにはデフォルトで提供されている Extension はない。したがって、JUnit4で ExternalResource とか TestName を使っていた場合は、自分で Extension を書かなければならない(まあ、誰かがそのうち作ってくれるだろうけど…)。

各インターフェースの詳細

ContainerExecutionCondition/TestExecutionCondition

テストコンテナ(テストクラス)/テスト(テストメソッド)の条件に基づき実行制御を判断するメソッドを提供するインターフェース。それぞれ ContainerExecutionContext および TestExtensionContext を引数にとって、 ConditionEvaluationResult を返す。 ContainerEvaluationResult はstaticメソッド enabled(String)(テストを実行する)または disabled(テストを実行しない)によって生成できるオブジェクト。アノテーション @Disabled によってテストの実行制御を行っているのも、このインターフェースを実装した DisabledConditionによる。

サンプルコード : 指定した曜日しか動かないテスト

github.com

テスト中のサービスの起動状態によって、モックを使ったテストを実行する/テスト中のサービスでテストを実行するなどの切り替えに使えるかもしれない(それなら Condition でやるよりも ParameterResolver の方がよいけど…)。

---

各 Callback インターフェース

テストの各種フェーズをhookにして起動できる処理を定義する。起動される順序は上述のとおり。またJUnit5のドキュメントに書かれているようにテストの実行時間を計測したい場合は、テストクラスの @BeforeEach/@AfterEach ではなく @BeforeTestExecutionCallback および @AfterTestExecutionCallback によって計測するほうがより正確な実行時間が計測できる。

---

例外ハンドリング

TestExecutionExceptionHandler によって例外発生時の処理を挟み込むことができる。まあ、特定の例外は無視するくらいの使いみちしかないと思われるが…

TestInstancePostProcessor

テストクラスのインスタンスを起動した後に、特定の処理をおこないたい場合やDI、モックの準備をしたい場合などに作る。

サンプルコード

@PostConstruct アノテーションが付与されているメソッドを起動する TestInstancePostProcessor

public class PostProcessor implements TestInstancePostProcessor {

  private static final Predicate<Method> annotatedWithPostConstruct =
      m -> m.isAnnotationPresent(PostConstruct.class);

  @NotNull
  private static Consumer<Method> invokePostConstruct(
      @NotNull Object o
  ) {
    return m -> {
      try {
        m.setAccessible(true);
        m.invoke(o);
      } catch (IllegalAccessException | InvocationTargetException e) {
        final String name = m.getName();
        throw new IllegalStateException(name + " method cannot be invoked.", e);
      }
    };
  }

  @Override
  public void postProcessTestInstance(
      Object test
      , ExtensionContext context
  ) throws Exception {
    Stream.of(test.getClass().getDeclaredMethods())
        .filter(annotatedWithPostConstruct)
        .findAny()
        .ifPresent(invokePostConstruct(test));
  }
}

サンプルコード続きはこちら

github.com

---

ParameterResolver

ParameterResolver はテストメソッドの引数を解決するインターフェース。 support メソッドで引数を渡すことができるか判断し、引数を渡せる場合に resolve メソッドで実際の引数を渡す。メソッドに引数を渡せると聞くと、それ自身がテストのassertionの対象となる値を渡せると捉えがちだが、どちらかというとテストに関するメタ情報や特別な処理が必要になるオブジェクト(DI管理のオブジェクトやDIの対象となるオブジェクト、モックオブジェクトなど)を引数にとるようにする。(テストのためのパラメーターについては、 DynamicTest で作ればよく、テストのメソッドの引数にはそのパラメーターを作るためのオブジェクト(例えば File など)を渡した方がよい)。

サンプルコード

@InputString アノテーションを付与した String 型の引数に @InputString のパラメーターで指定した文字列を渡す。

github.com

JUnit入門(4) - TestFactoryとDynamicTest - JUnit5におけるパラメタライズドテスト実現法

前回の続き

@TestFactory

@TestFactory はJUnit4における Theories ランナーを用いたテストパラメーターをいろいろと組み合わせるテストを実現するために用いる。

@TestFactory を付与したメソッドは次のいずれかを返すメソッドを実装する必要がある。

• Iterable<DynamicTest>
• Iterator<DynamicTest>
• Stream<DynamicTest>

DynamicTest はテストの名前とテストを持つクラスで、 DynamicTest#dynamicTest(String, Executable) から作ることができる。DynamicTest のインスタンス一つにつきテスト1つとしてカウントされる。なお、javadocを読むかぎり @Test を付与したテストとは違い、 DynamicTest の実行の前後に @BeforeEach と @AfterEach は実行されない。

サンプルコード

public class DynamicTestSample {

  @TestFactory
  Iterable<DynamicTest> dynamicTestIterable() {
    return Arrays.asList(
            dynamicTest("1 + 2 = 3", () -> assertEquals(3, 1 + 2))
            , dynamicTest("1 - 2 = -1", () -> assertEquals(-1, 1 - 2))
    );
  }

  @TestFactory
  Stream<DynamicTest> dynamicTestStream() {
    return Stream.of(
            new ThreeInts(1, 2, 3)
            , new ThreeInts(1, -2, -1)
    ).map(t -> dynamicTest(t.getTitle(), t.getTest()));
  }

  static class ThreeInts {
    final int left;
    final int right;
    final int result;

    ThreeInts(int left, int right, int result) {
      this.left = left;
      this.right = right;
      this.result = result;
    }

    String getTitle() {
      final String c = right < 0 ? "%d - %d = %d" : "%d + %d = %d";
      return String.format(c, left, Math.abs(right), result);
    }

    Executable getTest() {
      return () -> assertEquals(result, left + right);
    }
  }
}

実行結果

[         4 containers found      ]
[         0 containers skipped    ]
[         4 containers started    ]
[         0 containers aborted    ]
[         4 containers successful ]
[         0 containers failed     ]
[         4 tests found           ]
[         0 tests skipped         ]
[         4 tests started         ]
[         0 tests aborted         ]
[         4 tests successful      ]
[         0 tests failed          ]

@TestFactory のメソッドは2つだが、それぞれが2つずつテストを返して合計4つのテストが実行されている。

---

JUnit4で Theories ランナーで @DataPoints でデータを作っていた部分が、 DynamicTest 列の生成に置き換わり、 @Theory で行っていたテストそのものが DynamicTest に渡す Executable に置き換わったと考えるとわかりやすいかもしれません。

---

参考

github.com

---

続く

JUnit5入門(3) - アノテーション

前回の続き

JUnit4同様、JUnit5ではテストのメタ情報や、実行制御はアノテーションを介して行われる。今回はそのアノテーションをまとめる。

JUnit5が提供するアノテーション一覧

アノテーション	役割	説明
@Test	メタ情報	付与されたメソッドがテストであることを示す
@TestFactory	メタ情報	付与されたメソッドが返す Iterable などがテストであることを示す
@DisplayName	メタ情報	テストの表示名を付与する
@Nested	メタ情報	テストクラスのインナーテストクラスであることを示す
@Tag	実行制御	テストにタグを付与して
@Tags	実行制御	複数の @Tag をまとめる
@Disabled	実行制御	付与されたテスト/テストクラスは実行されない
@BeforeAll	メソッド実行順	付与されたstaticメソッドはテストクラスで最初に実行される
@BeforeEach	メソッド実行順	付与されたメソッドは各テスト/インナーテストクラスが実行される前に実行される
@AfterEach	メソッド実行順	付与されたメソッドは各テスト/インナーテストクラスが実行された後に実行される
@AfterAll	メソッド実行順	付与されたstaticメソッドはテストクラスで最後に実行される

各アノテーション詳細

@Test は既に説明済み、 @TestFactory は後ほど説明するとして、その他のアノテーションについて触れておく。

@DisplayName

テストの表示名を設定する。これまでもテスト名でキャメルケースを活用したり、日本語名を用いたりしてテストの内容を説明できるようにしてきたが、メソッド名はシンプルな名前にしておいて、 @DisplayName でよりわかりやすい名前をつけたり、名前に半角ブランクをつけられるようになった。

サンプルコード

@Test
@DisplayName("This test checks int value.")
void checkingInt() {
  assertEquals(2, asInt()); // わざとfail
}
@Test
@DisplayName("This test checks double value.")
void checkingDouble() {
  assertEquals(65535/65536.0, asDouble(), 1/128.0);
}

private static final int ONE = 1;
private static int asInt() {
  return ONE;
}
private static double asDouble() {
  return ONE;
}

実行結果

Failures (1):
  JUnit Jupiter:表示名を変えるテスト:This test checks int value.
    MethodSource [className = 'com.example.ex3.DisplayNameTest', methodName = 'checkingInt', methodParameterTypes = '']
    => org.opentest4j.AssertionFailedError: expected: <2> but was: <1>

また、このようなこともできる。

@Test
@DisplayName("This test checks\n" +
    "int value.")
void checkingInt() {
  assertEquals(2, asInt()); // わざとfail
}

Failures (1):
  JUnit Jupiter:表示名を変えるテスト:This test checkes
int value
    MethodSource [className = 'com.example.ex3.DisplayNameTest', methodName = 'checkingInt', methodParameterTypes = '']
    => org.opentest4j.AssertionFailedError: expected: <2> but was: <1>

テスト名に改行を入れることができるので、次のようにテストに関するドキュメントを記述しておくことが可能になる(ただしこの例はkotlinだが…)。

@Test
@DisplayName("""
文字列のチェック
---

このテストは次のチェックを行う

* 小文字にしたときに同じ文字列であること
* 文字列の長さが同じであること
""")
fun multipleLineDisplayName() {
  String japan = "JAPAN";
  assertAll(
      () -> assertEquals("japan", japan.toLowerCase())
      , () -> assertEquals(5, japan.length())
  );
}

@Nested

複数のテストをまとめて見通しを良くするために Enclosed.class ランナーを用いてインナークラスで整理する手法はJUnit4でもあったが、JUnit5でも利用できる。ただし、JUnit4ではインナークラスはstaticクラスである必要があったのに対して、JUnit5ではstaticクラスを使うことができなくなった。

サンプルコード

@Slf4j
@DisplayName("トップ")
public class NestedClasses {

  @Test
  @DisplayName("トップのテスト")
  void test() {
    log.info("トップのテスト");
  }

  @Nested
  @DisplayName("ミドル")
  class MiddleInner {

    @Test
    @DisplayName("ミドルにあるテスト")
    void test() {
      log.info("ミドルにあるテスト");
    }

    @Nested
    @DisplayName("ボトム")
    class MostInner {

      @Test
      @DisplayName("ボトムのテスト")
      void test() {
        log.info("ボトムのテスト");
      }
    }
  }
}

実行結果

21:24:43.608 [INFO  com.example.ex4.NestedClasses] - トップのテスト
21:24:43.630 [INFO  com.example.ex4.NestedClasses] - ミドルにあるテスト
21:24:43.659 [INFO  com.example.ex4.NestedClasses] - ボトムのテスト

なお、IntelliJで実行すると…

@DisplayName が省略される

実行順に関するアノテーション

@BeforeAll などのアノテーションが付与されたテストは次の順序で実行される。

1. @BeforeAll が付与されたstaticメソッド
2. @BeforeEach が付与されたメソッド
3. @Test または @TestFactory が付与されたメソッド
4. @AfterEach が付与されたメソッド
5. @BeforeEach が付与されたメソッド
6. @Test または @TestFactory ...
7. ...
8. @AfterEach が付与されたメソッド
9. @AfterAll が付与されたstaticメソッド

JUnit4のアノテーションと対応は次のようになる。

JUnit4	JUnit5
@BeforeClass	@BeforeAll
@Before	@BeforeEach
@After	@AfterEach
@AfterClass	@AfterAll

サンプルコード

@Slf4j
public class ExecutionModel {

  @BeforeAll
  static void beforeAll() throws InterruptedException {
    log.info("beforeAll");
  }

  @AfterAll
  static void afterAll() throws InterruptedException {
    log.info("afterAll");
  }

  @BeforeEach
  void beforeEach() throws InterruptedException {
    log.info("beforeEach");
  }

  @AfterEach
  void afterEach() throws InterruptedException {
    log.info("afterEach");
  }

  @Test
  void testFirst() throws InterruptedException {
    log.info("testFirst");
  }

  @Test
  void testSecond() throws InterruptedException {
    log.info("testSecond");
  }

  @Test
  void testThird() throws InterruptedException {
    log.info("testThird");
  }
}

実行結果

22:15:39.626 [INFO  com.example.ex3.ExecutionModel] - beforeAll
22:15:39.633 [INFO  com.example.ex3.ExecutionModel] - beforeEach
22:15:39.636 [INFO  com.example.ex3.ExecutionModel] - testFirst
22:15:39.642 [INFO  com.example.ex3.ExecutionModel] - afterEach
22:15:39.649 [INFO  com.example.ex3.ExecutionModel] - beforeEach
22:15:39.649 [INFO  com.example.ex3.ExecutionModel] - testSecond
22:15:39.649 [INFO  com.example.ex3.ExecutionModel] - afterEach
22:15:39.651 [INFO  com.example.ex3.ExecutionModel] - beforeEach
22:15:39.651 [INFO  com.example.ex3.ExecutionModel] - testThird
22:15:39.651 [INFO  com.example.ex3.ExecutionModel] - afterEach
22:15:39.653 [INFO  com.example.ex3.ExecutionModel] - afterAll

@Disabled

@Disabled はクラスまたはメソッドに付与してテストを実行させないようにすることができる。JUnit4における @Ignore に相当する。

@DisplayName("除外するテストの例")
public class DisablingTests {

  @Test
  @Disabled
  @DisplayName("動かさないテスト")
  void thisTestWillFail() {
    fail("動かさないテスト");
  }

  @Test
  @DisplayName("動かすテスト")
  void thisTestCanBeRunnable() {
    assertEquals(1, 1);
  }

  @Nested
  @DisplayName("動かすインナークラス")
  class WorkingInner {

    @Test
    @Disabled
    @DisplayName("動かさないテスト")
    void notWorking() {
      fail("not working now.");
    }

    @Test
    @DisplayName("動かすテスト")
    void working() {
      assertTrue(true);
    }
  }

  @Nested
  @Disabled
  @DisplayName("動かさないインナークラス")
  class NotWorking {

    @Test
    @Disabled
    @DisplayName("動かさないテスト")
    void notWorking() {
      fail("not working now.");
    }

    @Test
    @DisplayName("動かすテスト")
    void working() {
      assertTrue(true);
    }
  }
}

実行結果

[         4 containers found      ]
[         1 containers skipped    ]
[         3 containers started    ]
[         0 containers aborted    ]
[         3 containers successful ]
[         0 containers failed     ]
[         6 tests found           ]
[         4 tests skipped         ]
[         2 tests started         ]
[         0 tests aborted         ]
[         2 tests successful      ]
[         0 tests failed          ]

親クラスのテストが2つ(@Disabled 1つ)、 実行する方の子クラスのテストが2つ(@Disabled 1つ)、実行しない(@Disabled)子クラスのテストが2つの合計6つテストがあり、スキップされたのが @Disabled が付与された4つ(1 + 1 + 2)であり、実行されたテストは2つであることが結果からもわかる。

@Tag/@Tags

@Tag は実行制御に関するアノテーションと書いたが、実際の所テストにメタ情報をつけるだけで、IDEから実行する際には特に意味がない(今後タグを識別して実行するようになるかもしれないが…)。gradleなどのplatformからテストを実行する場合にタグ情報をテスト実行制御に用いる。JUnit4における @Categoies に相当する。

サンプルコード

@Slf4j
@DisplayName("タグをつけたテスト")
public class TaggedTests {

  @Test
  @Tag("one")
  @DisplayName("1st というタグを付けたテスト(タグはIDEで実行する上では特に意味がない)")
  void test1st() {
    log.info("1st");
  }

  @Test
  @Tag("two")
  @DisplayName("two という タグ")
  void test2nd() {
    log.info("2nd");
  }

  @Test
  @Tags({
      @Tag("one")
      , @Tag("two")
      , @Tag("three")
  })
  @DisplayName("Tagsでタグたくさん")
  void test3rd() {
    log.info("3rd");
  }

  @Test
  @Tag("one")
  @Tag("three")
  @Tag("this is four")
  @DisplayName("Tagsの中にではなく、Tagをたくさん")
  void test4th() {
    log.info("4th");
  }

  @Test
  @Tag("two")
  @Tag("three")
  @Tag("this is five")
  @DisplayName("Tagsの中にではなく、Tagをたくさん")
  void test5th() {
    log.info("5th");
  }
}

実行結果

22:37:14.794 [INFO  com.example.ex5.TaggedTests] - 1st
22:37:14.806 [INFO  com.example.ex5.TaggedTests] - 3rd
22:37:14.808 [INFO  com.example.ex5.TaggedTests] - 2nd
22:37:14.810 [INFO  com.example.ex5.TaggedTests] - 4th
22:37:14.813 [INFO  com.example.ex5.TaggedTests] - 5th

特に設定をしない限りはすべてのテストが実行される。

JUnit5で @Tag の値に基づき実行を制御するためには、 build.gradle の junitPlatform クロージャー中に次のような記述を行う。

例(twoタグを除外する場合)

junitPlatform {
  filters {
    tags {
      exclude 'two'
    }
  }
}

実行結果

22:59:23.964 [INFO  com.example.ex5.TaggedTests] - 1st
22:59:23.973 [INFO  com.example.ex5.TaggedTests] - 4th

Test run finished after 10321 ms
[         2 containers found      ]
[         0 containers skipped    ]
[         2 containers started    ]
[         0 containers aborted    ]
[         2 containers successful ]
[         0 containers failed     ]
[         2 tests found           ]
[         0 tests skipped         ]
[         2 tests started         ]
[         0 tests aborted         ]
[         2 tests successful      ]
[         0 tests failed          ]

@Tag("two") が付与された test2nd 、 test3rd 、 test5th は実行されず、またテストとしてもカウントされてないことに注意したい。

例(exclude 、 include を指定した場合)

junitPlatform {
  filters {
    tags {
      exclude 'two'
      include 'three'
    }
  }
}

実行結果

23:04:13.315 [INFO  com.example.ex5.TaggedTests] - 4th

two が付与されておらず three が付与されている test4th が実行された。

サンプルコードはこちら

github.com

github.com

github.com

---

つづく

JUnit5入門(2) - アサーション

前回 の続き

今回は値の比較、アサーションについて。

---

JUnit5が提供するアサーション

JUnit5はJUnit4とほぼ同等のAssertion機能を提供している。また、より高度なAssertionを求める場合は、サードパーティライブラリーの利用を勧めている。

JUnit5のAssertionの基本的なもの

以下の通り。なお、assertThat はなくなった。また、メッセージはこれまでは引数の最初に渡していたが、引数の最後に渡すようになった。

メソッド	比較内容
Assertions#assertEquals	左(期待値)と右(実際の値)が等しいことを確認する
Assertions#assertNotEquals	左(期待値)と右(実際の値)が等しくないことを確認する
Assertions#assertTrue	値が true であることを確認する
Assertions#assertFalse	値が false であることを確認する
Assertions#assertSame	左(期待するオブジェクト)と右(実際のオブジェクト)が同じインスタンスであることを確認する
Assertions#assertNotSame	左(期待しないオブジェクト)と右(実際のオブジェクト)が同じインスタンスでないことを確認する
Assertions#assertNull	値が null であることを確認する
Assertions#assertNotNull	値が null でないことを確認する
Assertions#assertArrayEquals	左の配列(期待値)と右の配列(実際の値)が順番、値ともに等しい配列であることを確認する

サンプルコード

@Test
void assertVariation() {
  assertEquals("2nd test", getText(), "メッセージは3つめの引数");
  assertEquals("2nd test", getText(), () -> "メッセージは Supplier でも渡せる");
  assertTrue(true, "これは [true]");
  assertFalse(false); // メッセージなし
  assertNotEquals("いろいろなassertion", getText());
  assertNotSame(new Something(), new Something(), () -> "notSame は reference の比較");
  assertSame(something, something);
  assertNotSame(something, new Something(), () -> "型が違うけど比較できる...");
  assertNull(returnsNull());
  assertNotNull(getText());
  assertArrayEquals(new int[]{1,2,3,4,5,6,7,8}, intArray(), () -> "配列のテスト");
}

private static final Object something = new Object();
private static class Something {}
@NotNull
private String getText() {
    return "2nd test";
}
@Nullable
private String returnsNull() {
  return null;
}
@NotNull
private static int[] intArray() {
  return new int[]{1, 2, 3, 4, 5, 6, 7, 8};
}

追加になったAssertion

Iterable の比較をおこなうassertionメソッド(Assertions#assertIterableEquals)が追加された。

サンプルコード

@Test
void assertionForCollections() {
  assertIterableEquals(Arrays.asList(
      new Identity<>(0)
      , new Identity<>(1)
      , new Identity<>(2)
      , new Identity<>(3)
  ), identityList());
}

@Data @RequiredArgsConstructor
static class Identity<T> {
  private final T id;
}
@NotNull
private List<Identity> identityList() {
  return IntStream.range(0, 4)
      .mapToObj(Identity::new)
      .collect(toList());
}

便利なAssertion

Assertions#assertAll という複数のAssertをサポートするメソッドが追加された。

可変長引数で渡された Executable(Assertionの式)または Stream<Executable> を受取りすべてのAssertionをすべて実行し、どれがfailしたかエラー表示する。

サンプルコード

@Test
void assertAllThatFails() {
  Stream<Executable> tests = IntStream.rangeClosed(1, 7)
      .mapToObj(i -> () -> {
        log.info("This is assertion[{}]", i);
        assertEquals(i, i + (i % 3 == 0? 1 : 0), () -> "assertion" + i);
      });
  assertAll(tests);
}

実行結果

19:06:46.940 [INFO  com.example.ex2.FourthTest] - This is assertion[1]
19:06:46.945 [INFO  com.example.ex2.FourthTest] - This is assertion[2]
19:06:46.946 [INFO  com.example.ex2.FourthTest] - This is assertion[3]
19:06:46.947 [INFO  com.example.ex2.FourthTest] - This is assertion[4]
19:06:46.947 [INFO  com.example.ex2.FourthTest] - This is assertion[5]
19:06:46.948 [INFO  com.example.ex2.FourthTest] - This is assertion[6]
19:06:46.948 [INFO  com.example.ex2.FourthTest] - This is assertion[7]

Failures (1):
  JUnit Jupiter:FourthTest:assertAllThatFails()
    MethodSource [className = 'com.example.ex2.FourthTest', methodName = 'assertAllThatFails', methodParameterTypes = '']
    => org.opentest4j.MultipleFailuresError: Multiple Failures (2 failures)
        assertion3 ==> expected: <3> but was: <4>
        assertion6 ==> expected: <6> but was: <7>

なお、複数のAssertionを実行してもテストは1としてしかカウントされない。

JUnit5のAssumption

Assumptionは条件に合致した場合のみテストを実行し、条件に合致しない場合にはテストをスキップするヘルパーメソッド。JUnit4にあった assumeThat や assumeNotNull 、 assumeNoException がなくなり、 assumeTrue が残った。また、 assumeFalse 、 assumingThat が追加された。

サンプルコード

@Test
void thisTestDoNotRunOnSunday() {
  final DayOfWeek dayOfWeek = today().getDayOfWeek();
  assumeFalse(SUNDAY.equals(dayOfWeek));
  log.info("日曜以外");
  assertFalse("日".equals(dayOfWeek.getDisplayName(TextStyle.SHORT, Locale.JAPAN)));
}
@Test
void thisTestRunOnSunday() {
  final DayOfWeek dayOfWeek = today().getDayOfWeek();
  assumeTrue(SUNDAY.equals(dayOfWeek));
  log.info("日曜");
  assertEquals("日", dayOfWeek.getDisplayName(TextStyle.SHORT, Locale.JAPAN));
}

private static final ZoneId ZONE_ID = ZoneId.of("Asia/Tokyo");
@NotNull @Contract(pure = true)
private static LocalDate today() {
  return LocalDate.now(ZONE_ID);
}

実行結果

Test run finished after 10468 ms
[         2 containers found      ]
[         0 containers skipped    ]
[         2 containers started    ]
[         0 containers aborted    ]
[         2 containers successful ]
[         0 containers failed     ]
[         1 tests found           ]
[         0 tests skipped         ]
[         1 tests started         ]
[         1 tests aborted         ]
[         0 tests successful      ]
[         0 tests failed          ]

---

assumingThat は最初の引数の BooleanSupplier が true を返した場合のみ後続の Executable(Assertion)が実行される。

assumingThat のサンプルコード

@Test
void thisTestDoNotRunOnSunday() {
  final DayOfWeek dayOfWeek = today().getDayOfWeek();
  assumingThat(
      () -> !SUNDAY.equals(dayOfWeek)
      , () -> assertFalse("日".equals(dayOfWeek.getDisplayName(TextStyle.SHORT, Locale.JAPAN)))
  );
}
@Test
void thisTestRunOnSunday() {
  final DayOfWeek dayOfWeek = today().getDayOfWeek();
  assumingThat(
      () -> SUNDAY.equals(dayOfWeek)
      , () -> assertEquals("日", dayOfWeek.getDisplayName(TextStyle.SHORT, Locale.JAPAN))
  );
}

実行結果

Test run finished after 10261 ms
[         2 containers found      ]
[         0 containers skipped    ]
[         2 containers started    ]
[         0 containers aborted    ]
[         2 containers successful ]
[         0 containers failed     ]
[         2 tests found           ]
[         0 tests skipped         ]
[         2 tests started         ]
[         0 tests aborted         ]
[         2 tests successful      ]
[         0 tests failed          ]

---

コードはこちらから

github.com