これで失敗しない! JUnit 5 へのマイグレーション方法

Transcript

1. 〜 大規模プロジェクトで効率的にマイグレーションする TIPS 〜 これで失敗しない！ JUnit 5 へのマイグレーション方法 @akkiee76 開発 × テスト LT 会 - vol.3 #devtest
2. 自己紹介 Akihiko Sato / @akkiee76 株式会社ラクス 楽楽精算開発 モバイル開発 / Lead Engineer SaaS (Backend, Frontend) / Mobile (iOS, Android) 主な業務は、設計 〜 受入、チームの課題改善など マイブームは、縄跳び・腹筋ローラー Twitter QR
3. 今日伝えたいこと 品質を保ちつつ効率よく JUnit 5 へ マイグレーションさせる TIPS
4. JUnit 5 へマイグレーションが必要になった経緯 私のチームが担当しているプロジェクトの中には、 Spring Framework を採用しているプロジェクトがありますが、 v 5.2 (Spring Boot 2.2) 以降へのアップデートに伴い JUnit 5 への移行が必要になりました。
5. JUnit 5 へマイグレーションの影響範囲 そこまで大規模プロジェクトではなかったが、 JUnit 5 へのマイグレーションにあって影響を受ける テストファイルは 50 ファイル程度 とはいえ、影響範囲はそこそこ。。
6. 具体的に必要な修正概要 1. package (import) の変更 2. アノテーションの置換 3. テスト階層化方法の変更 4. Assert テストの変更 が主な修正内容となりました。
7. 1. package (import) の変更 JUnit 4 では org.junit 配下の package にあったクラス群が JUnit 5 では org.junit.jupiter.api 配下となるため、 import の修正が必要になります。 対象 JUnit 4 JUnit 5 @Test など org.junit.* org.junit.jupiter.api.* Assertion など org.junit.Assert.* org.junit.jupiter.api.Assertions.*
8. 2. アノテーションの置換 具体的に置換が必要なアノテーション（一部） JUnit 4 JUnit 5 @Before @BeforeEach @After @AfterEach @BeforeClass @BeforeAll @AfterClass @AfterAll @Ignore @Disabled @Category @Tag https://blog.jetbrains.com/idea/2020/08/migrating-from-junit-4-to-junit-5/
9. 3. テスト階層化方法の変更 JUnit 5 からは @Nested が利用可能になるため、 テスト階層の記述が容易になります。 @RunWith(Enclosed.class) public class SampleJUnit4Test { public static class RelationalTest1 { @Test public void test() { ... } } public static class RelationalTest2 { @Test public void test() { ... } } } public class SampleJUnit5Test { @Nested class RelationalTest1 { @Test public void test() { ... } } @Nested class RelationalTest2 { @Test public void test() { ... } } } JUnit 4 JUnit 5
10. 4. Assert テストの変更 Assert の記述も変更になったため、修正が必要になります。 JUnit 4 @Test(expected = NullPointerException.class) public void testNullPointerException() { /* NullPointerException が発生するコード */ } @Test public void testNullPointerException() { assertThrows(NullPointerException.class, () -> { /* NullPointerException が発生するコード */ }); } JUnit 5
11. 4. Assert テストの変更 JUnit 4 @Rule public ExpectedException expectedException = ExpectedException.none(); @Test public void testExpectedException() { expectedException.expect(HogeException.class); expectedException.expectMessage("HogeException message"); /* HogeException が発生するコード */ } JUnit 5 @Test public void testExpectedException() { HogeException exception = assertThrows(HogeException.class, () -> { /* HogeException が発生するテストコード */ }); assertEquals("HogeException message", exception.getMessage()); }
12. マイグレーション対応中の課題 マイグレーション対応中は CI は失敗することになる。 本実装とテストコードの関係性は維持する必要があるため、 CI を維持しながらマイグレーションしてく方法はないか。。
13. マイグレーション対応中の課題 3.1. Running JUnit 4 Tests on the JUnit Platform Just make sure that the junit-vintage-engine artifact is in your test runtime path. In that case JUnit 3 and JUnit 4 tests will automatically be picked up by the JUnit Platform launcher. 公式ガイドラインを調べてみると、以下の記載を発見する。 https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4 junit-vintage-engine を使うことで JUnit 4 を維持しながら、 マイグレーションすることが可能ということが分かりました。
14. マイグレーション対応中の課題が解決 junit-vintage-engine を利用し、以下の方針で進めることに。 　 1. junit-vintage-engine を導入 　 2. import と annotation の修正 　 3. テスト階層化方法の修正 　 4. Assert の修正 　 5. junit-vintage-engine を削除
15. マイグレーション対応方針 とはいえ、対象ファイルが多いのでスコープを適度に細分化 　 2. import と annotation の修正（ボリューム大） ・各 package ごと 5 ファイル程度に分けて MR を対応 　 3. テスト階層化方法の修正 　　・適度な粒度の MR に分割 　 4. Assert の修正 　　・適度な粒度の MR に分割
16. マイグレーション対応方針 細分化のポイント 👉　 MR の changes は最大でも 10 程度にする ・スコープを小さくすることで修正の考慮漏れを少なくできる 👉　品質担保 ・チームで分担して作業しやすい 　　👉　作業効率化
17. 更に大規模プロジェクトの場合、スプレッドシートで一覧化して 対応していくと進捗も分かり易いです。 【 参考 】 Frontend ライブラリの アップデートで苦労した話 マイグレーション対応方針
18. まとめ JUnit 5 へマイグレーションのポイント 👉　 junit-vintage-engine を導入して JUnit 4 と共存させ CI を維持する 👉　 import 、アノテーション修正はスコープを分けて対応する 　　（修正のスコープはなるべく小さくする） 👉　修正ファイルが多い場合は、一覧化して進捗管理する
19. オンラインイベントや中途採用を積極的に行ってます！ 最後に
20. ご清聴ありがとうございました