Testing with JUnit 5 and Spring
本セッションでは、VMWareのエンジニアであるSam Brannen氏から、JUnit 5.7 / 5.8（Jupiter）、およびSpring Framework 5.3、GraalVM関連のテスト（以下本節で「テスト」と述べる時は「JUnitテスト」を指す）に関する主な新機能についての紹介がありました。
Gareth氏はまずJUnit 5.7の主要な機能として、Java Flight Recorderのサポートやテスト実行順序の設定方法、テストの実行条件を規定するアノテーションや、ボイラーコードを削減する工夫など、5つのトピックを紹介しました。例えばJava Flight Recorderのサポートでは、テスト実行時にJava Flight Recorderのイベントを生成することができるようになる等、JUnit利用者の利便性が向上します。
Release Candidate 1（RC1）が公開されたJUnit 5.8では、主要な機能としてテストスイート（まとめて実行するテストの集合）を宣言する方法（アノテーション）が変更になり、またテストスイートに関するいくつかの新しいアノテーションが追加されました。これにより宣言的にテストスイートを用意し、ひとまとめに実行することが容易になりました。
さらにもう一つの重要な要素として、すべてのテストにユニークなIDを付与し、その実行履歴をファイルに出力することができるようになりました。これによりテスト実行結果の追跡や、実行順序を完全に再現しながら何度でもテストを実行することができます。
Spring Framework 5.3では、GA後にメンテナンスリリースとして、ボイラープレート・コードを削減するためのアノテーションやデフォルト設定、テスト実行中のApplicationEventsの捕捉、複数の「@Autowired」が付与されるテスト実行時に発生する不具合の検出などの機能が追加され、利便性が向上しました
GraalVM（厳密にはGraalVM Native Build Tools）関連のテストについては、まず「なぜNative Image内でアプリケーションの内部構造に着目した（ホワイトボックス）テストが必要なのか？」という問いに答える必要があると思います。
Native Imageは通常のJavaアプリケーションとは異なり、JVM上で動作しません。もちろんNative Imageの外部から（例えばHTTPエンドポイントを利用して）ブラックボックス・テストを実行することは可能ですが、アプリケーションの全ての機能にHTTPエンドポイントが存在することはむしろ稀です。したがってNative Image内でアプリケーションの動作が想定通り行われているか否かを確認するには、Native Imageの内部でテストを実行する必要があります。GraalVM Native Build Toolsを利用することで、そのような「アプリケーションの内部構造に着目したテストコード」をNative Imageに再利用することができます。
ただしNative Imageのテストにおいてはいくつか注意すべき点があります。クラスパスのスキャンやMockitを始めとするモックライブラリが動作しません。そのため（カスタムの）tagアノテーションを用いてNative Image 内部で実行するテストを区別することを推奨しています。またNative Imageのビルドには数十分程度かかることもあるため、専用のCIパイプラインを夜間に動作させるなどの工夫が必要になります。
その後は、本セッションで紹介した機能を5分ほどのデモで紹介し、セッションを締めくくりました。
Packaging and Distributing Applications for Kubernetes
VMWareのIan Zink氏とNitasha Verma氏による本セッションでは、主に、Kubernetes環境で効率的にアプリケーションをパッケージング・配布する方法が紹介されました。
Kubernetes環境におけるアプリケーションは、コーディング作業に加え一般的に以下の作業が必要になります。
- 設定ファイル（マニフェスト等）の作成
- パッケージングおよび配布
- 設定のカスタマイズ
- クラスタへのデプロイ
このライフサイクルの各ステージを効率的に処理するソリューションとして紹介されたのがCarvelです。Carvelは、以下のような複数のツールから構成されます。
- ytt：設定ファイルのテンプレート化（変数の埋め込みなど）とオーバーレイ化（既存YAMLファイルをもとに変更を加える機能）が可能
- kbld：コンテナー・イメージのビルドとプッシュを開発ワークフローにシームレスに組み込む
- kapp：複数のKubernetesリソースを1つの「アプリケーション」としてデプロイやアンデプロイなどが可能
- imgpkg：設定ファイルなど任意のファイルの集合を、OCI（Open Container Initiative）準拠のイメージとしてバンドルし、コンテナー・レジストリに格納することが可能
デモでは、マイクロサービスを開発しそれらのイメージの作成／登録を行う「デベロッパー」と、デベロッパーが登録したマイクロサービスイメージを必要に応じてカスタマイズして実際のアプリケーションを構築／運用する「コンシューマー」に分かれ、上述のツールを駆使することでCI/CDパイプライン関連の作業が効率化され、デベロッパー環境からコンシューマー環境へ、素早くかつ誤りなくアプリケーションの更新が行えることを示しました。
またセッション終盤では、CRD（Custom Resource Definitions）によるKubernetesネイティブの継続的デリバリーや、パッケージ管理を提供するkapp-controllerについても言及されていました。
クラウドネイティブなアプローチが加速している今、CarvelのようなKubernetes周辺ツールの進展も著しいため、それらの動向についても注視していく必要がありそうです。
