JUnit, 4, 5, Jupiter, Vintage

JUnit 5がリリースされた後、多くの開発者はこの素晴らしい新しいライブラリをプロジェクトに追加しました。なぜなら、他のバージョンとは異なり、この新しいバージョンではJUnit 4から5への移行は必要なく、新しいライブラリをプロジェクトに含めるだけで、JUnit 5のすべてのエンジンを使用して新しいテストを行うことができ、古いJUnit 4や3のテストは問題なく実行され続けます。

しかし、10年前にビルドされた、JUnitの2つのバージョンが並行して動作する大きなプロジェクトでは、どうなるのでしょうか？

新しい開発者がプロジェクトに参加し始め、JUnitの経験がある人もいれば、いない人もいます。新しいテストはJUnit 5で作成され、新しいテストはJUnit 4で作成されます。どこかの時点で、知識不足の開発者がJUnit 5のテストに新しいシナリオを作成する際に、JUnit 4のアノテーションを含めるだけで、テストが混合され、JUnit 4の@TestとJUnit 5の@Testが混在し、JUnit 4のライブラリを削除することが cada 日どんどん難しくなります。

それでは、この問題をどのように解決するのでしょうか？まず最初に、チームにJUnit 5とJUnit 4の区別を示し、新しいテストはJUnit 5で作成するように指示します。その後、ボーイ・スカウトのルールに従い、JUnit 4のテストを通過するたびにJUnit 5に移行する必要があります。

JUnit 5でリリースされた主な変更を見てみましょう。まず名前から始めます。JUnit 5では、org.junit5というパッケージはなく、代わりにorg.junit.jupiterを使用しています。要するに、「Jupiter」と書かれているものはすべてJUnit 5のものです。この名前は、Jupiterが「JU」で始まり、太陽から5番目の惑星であることに由来しています。

また、@Testアノテーションも変更されています。このアノテーションは新しいパッケージに移動され、org.junit.jupiter.apiとなっています。そして「expected」や「timeout」といった属性はもはや使用されません。代わりにエクステンションを使用します。例えば、タイムアウトの場合は以下のアノテーションを使用します：@Timeout(value = 100, unit = TimeUnit.MILLISECONDS)。もう一つの変更は、テストメソッドやクラスがpublicである必要がないことです。

テスト設定で@Beforeや@Afterを使用する代わりに、@BeforeEachや@AfterEachを使用する必要があります。また、@BeforeAllや@AfterAllも追加されています。

テストを無視する際には、@Ignoreの代わりに@Disableを使用する必要があります。

A great news that was released in JUnit 5 was the annotation @ParameterizedTest, with that is possible to run one test multiple times with different arguments. For example, if you want to test a method that creates some object and you want to validate if the fields are filled correctly, you just do the following:

@ParameterizedTest
@MethodSource("getInvalidSources")
void shouldCheckInvalidFields(String name, String job, String expectedMessage) {
	Throwable exception = catchThrowable(() -> new Client(name, job));
  
  	assertThat(exception).isInstanceOf(IllegalArgumentException.class)
      .hasMessageContaining(expectedMessage);
}

static Stream<Arguments> getInvalidSources() {
	return Stream.of(Arguments.arguments("Jean Donato", "", "Job is empty"),
                     Arguments.arguments("", "Dev", "Name is empty"));
}

JUnit 5には非常に多くの素晴らしい機能があります。JUnit 5のユーザーガイドをチェックして、プロジェクトに役立つものを見極めてみることをお勧めします。

現在、すべての開発者がJUnit 5で何が変更されたかを把握しているので、プロジェクトからJUnit 4を削除するプロセスを開始できます。したがって、2024年にまだJUnit 4を使用しており、プロジェクトが大規模なプロジェクトである場合、JUnit 4を使用する依存関係を持っているかもしれません。あなたのライブラリを分析して、いくつかがJUnit 4を使用しているか確認することを推奨します。

以下の画像では、IntelliJのDependency Analyzerを使用しています。

見ての通り、jersey-testはJUnit 4を使用しており、つまり私がプロジェクトからJUnit 4を削除しても、JerseyのためにJUnit 4が使用可能になるでしょう。簡単な方法は、jerseyを2.35にバンプすることですが、JUnit 5がjersey-test 2.35で導入されたため、jersey-test フレームワークをアップデートすることはできません。他のライブラリがプロジェクトで壊れるためです。この場合、どうすればよいでしょうか？

I can exclude JUnit from Jersey with Dependency Exclusions from Maven (like the image below). That way JUnit 4 will not be used anymore, but rather our JUnit 5. 

Jerseyを使用するいくつかのテストを実行すると、メソッドがロードされません。なぜなら、JerseyにはJUnit 4アノテーションを使用したsetUpとtearDownメソッドがあって、@Beforeと@Afterを使用しているからです。この問題を解決するために、「設定クラス」を作成し、JerseyTestを継承し、setUpとtearDownを@BeforeEachと@AfterEachで実装し、super.setUp()とsuper.TearDown()を呼び出すことができます。

public class JerseyConfigToJUnit5 extends JerseyTest {

  @BeforeEach
  public void setUp() throws Exception {
  	super.setUp();
  }
  
  @AfterEach
  public void tearDown() throws Exception {
  	super.tearDown();
  }
}

もしあなたがすでにライブラリを確認し、誰もJUnit 4に依存していないことを確認したら、やっと全てのテストをJUnit 5に移行することができます。このプロセスには、多くの労力を節約してくれる優れたツールがあります。それはOpenRewriteで、ソースコードのための自動リファクタリングエコシステムです。これにより、古いパッケージや古いアノテーションなど、すべてを新しいものに変更します。

それで、皆さん、もう終わりです。あなたとあなたのチームメイトはJUnit 5を楽しむことができ、新しいテストがJUnit 5で作成され、プロジェクトがフランケンシュタインにならないと安心できます。ですから、プロジェクトを最新の状態に保ち続けることを忘れないでください。ライブラリを見落とすと、毎日更新が難しくなります。常に仕様に従う規格やフレームワークを使用し、コードに良い設計を持つようにしてください。これにより、変更や移行が容易になります。