JUnit、4、5、木星、レトロ

JUnit 5 のリリースでは、JUnit 4 から移行する必要がないため、このライブラリをプロジェクトに統合することが簡単になります。ただし、JUnit 5 と 4 の両方を使用する大規模なプロジェクトでは、この共存により混乱が生じ、メンテナンスが困難になる可能性があります。この問題を解決するために、この記事では次の手順を実行することをお勧めします。JUnit 5 の新機能についてチームに通知し、JUnit 5 を使用して新しいテストを作成することを奨励し、JUnit 4 を削除する場合は Scout ルールに従うことです。さらに、この記事では、アノテーション、メソッド、テスト構成の更新や、新しい @ParameterizedTest アノテーションなど、JUnit 5 の注目すべき変更点についても説明します。最後に、この記事では、JUnit 5 への移行とプロジェクトを最新の状態に保つために、依存関係の除外、構成クラスの作成、OpenRewrite を使用してソース コードを自動的にリファクタリングすることの重要性を強調しています。

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

しかし、10 年前に構築されたプロジェクトで、2 つのバージョンの JUnit が並行して実行されている大規模なプロジェクトでは何が起こるでしょうか?

新しい開発者がプロ​​ジェクトに取り組み始めましたが、その中には JUnit の経験のある人もいない人もいます。新しいテストは JUnit 5 を使用して作成され、新しいテストは JUnit 4 を使用して作成されます。開発者は、ある時点で、作成済みの JUnit 5 テストに新しいシナリオを作成すると、JUnit 4 のアノテーションが含まれるだけになり、テストがハイブリッドになってしまいます。一部の @Test は JUnit 4 であり、一部の @Test は JUnit 5 であり、JUnit 4 ライブラリを毎日削除するのが難しくなりました。

それでは、この問題をどうやって解決すればいいのでしょうか?まず、JUnit 4 の代わりに JUnit 5 を使用して新しいテストを作成できるように、JUnit 5 に由来するものと JUnit 4 に由来するものをチームに示す必要があります。その後、ボーイ スカウトの規則に従って JUnit 4 テストに合格するたびに、JUnit 5 に移行する必要があります。

JUnit 5 でリリースされた主な変更点を見てみましょう。すべては名前から始まります。JUnit 5 では、org.junit5 という名前のパッケージは表示されず、org.junit.jupiter という名前が表示されます。全体として、表示されるものにはすべて「Jupiter」が含まれており、これは JUnit 5 のものであることを意味します。 「JU」で始まる木星が太陽から5番目の惑星であることから、この名前が付けられました。

もう 1 つの変更は @Test に関するもので、このアノテーションは新しいパッケージ org.junit.jupiter.api に移動され、「expected」や「timeout」などのプロパティは使用されなくなりましたが、拡張機能が使用されます。たとえば、タイムアウトの場合、@Timeout(value = 100, Unit = TimeUnit.MILLISECONDS) という注釈が追加されました。もう 1 つの変更点は、テスト メソッドもクラスもパブリックにする必要がないことです。

@@After の代わりに Before Now をテスト構成で使用する必要があり、@BeforeAll と @AfterAll もあります。

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

JUnit 5 でリリースされた良いニュースの 1 つは、アノテーション @ParameterizedTest であり、これは 1 つを複数回実行できます。さまざまなパラメータを使用してテストします。たとえば、オブジェクトを作成するメソッドをテストし、フィールドが正しく入力されていることを確認したい場合は、単に次の操作を実行します:

@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 JUnit 5 には優れた機能がたくさんあります。JUnit 5 ユーザー ガイドを参照して、プロジェクトにどの機能が役立つかを分析することをお勧めします。

すべての開発者が JUnit 5 の変更点を理解したので、プロジェクトから JUnit 4 を削除するプロセスを開始できます。したがって、2024 年になっても JUnit 4 を使用しており、プロジェクトが大規模な場合は、JUnit 4 を使用する依存関係がいくつか存在する可能性があります。ライブラリをプロファイリングして、一部のライブラリが JUnit 4 を使用しているかどうかを確認することをお勧めします。

下の画像では、IntelliJ の依存関係アナライザーを使用しています。

ご覧のとおり、jersey-test は JUnit 4 を使用しています。つまり、プロジェクトから JUnit 4 を削除しても、Jersey のおかげで JUnit 4 は引き続き動作します。 JUnit 5 がジャージーテスト 2.35 で導入されたため、より簡単な方法はジャージーを 2.35 にアップグレードすることですが、プロジェクトで他のライブラリが壊れてしまうため、ジャージーテストフレームワークを更新できません。では、この状況では何ができるでしょうか?

Maven の依存関係の除外を使用して、JUnit を Jersey から除外できます (下の図を参照)。これでは JUnit 4 は使用されなくなり、JUnit 5 が使用されます。

当你运行一些使用Jersey的测试时，它们不会被加载，因为Jersey中有使用JUnit 4注释的方法，setUpand tearDown，using@Before和@After。为了解决这个问题，您可以创建一个“配置类”，其扩展JerseyTest实现setUpandtearDown并@BeforeEach调用@AfterEachand 。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 创建新测试，并且该项目不会成为弗兰肯斯坦。所以，记住，保持你的项目是最新的，因为如果你忘记了你的库，每一天都会更难更新，总是使用规范，以及遵循规范的框架，并且在你的代码中有一个好的设计，这允许您随设施改变和移动。

以上がJUnit、4、5、木星、レトロの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。