マイクロサービスにおけるテスト自動化とテスト戦略

本連載の第1回で、マイクロサービスの一般的な特徴やメリットについて紹介しました。その際、マイクロサービスでは開発体制やアプリケーション構成、リリース単位などについて、「これまでとは異なるかたちで行うことを要求される」とご説明したかと思います。

実際のプロジェクトでマイクロサービスアーキテクチャを採用する場合、アプリケーションを迅速にリリースし、顧客やエンドユーザーの要求／フィードバックに応じて機能追加や仕様変更を行っていくケースが多いでしょう。

機能追加などでアプリケーションを改修する場合、追加した部分のテストはもちろん、リファクタリングのほか、変更が入っていない既存部分も無影響確認テストなどを繰り返し実施する必要があります。そのため、試験においてはテストコードを実装し、ソースコードコミットやビルド時にテストを実行するなどして、改修時の問題の早期検出の仕組みを整えること、また、継続的インテグレーションによって極力自動化し、修正にかかる工数を省力化しておくことが重要になります。

とはいえ、テストコードの実装には相応の工数が必要です(筆者の感覚値ですが、アプリケーションコードの実装に比べてテストコードの実装はその3倍近い工数がかかる場合もあります)。

初めから完璧にテストコードを整備しておく必要もありませんし、必要以上のテストコードの実装でかえって開発のアジリティを損なうようでは本末転倒です。ただ、テストがおろそかになるとせっかくの継続的インテグレーションも機能しません。

開発のスピードと品質を両立するには、テスト計画やスコープ、検証の観点を明示的に定めておくことが重要です。以降では、どのようなテスト戦略の下で、どんなテストを実施すべきか、SpringBootを使ったアプリケーションテスト実装を通して実践していきます。

アプリケーションのパッケージ／コンポーネント構成

テスト戦略の話に入る前に、本連載で構築するマイクロサービスアーキテクチャでのアプリケーションのパッケージ／コンポーネント構成について説明します。アプリケーションでは、以下のようにBackendとBackendForFrontend(BFF)に分けてコンテナを構築しています。

本連載では、Backendでデプロイしているアプリケーションがマイクロサービスに相当します。そして、各マイクロサービスを呼び出し、呼び出した結果をフロントエンド(クライアント)向けに画面(HTML)などにアグリゲーション(集約)して返却するのが、BFFの役割です。

また、Backend、BFFともにアプリケーションのコンポーネントはそれぞれ、アプリケーションレイヤ、ドメインレイヤ、インフラストラクチャレイヤで分割して構成するものとします。

以降登場する各レイヤやコンポーネントの用語の意味や役割はTERASOLUNAのガイドライン「アプリケーションのレイヤ化」での記述にほぼ準拠するので、必要に応じて、TERASOLUNAのサイトを参照してください。

なお、実際に作成したアプリケーションはGitHub上にコミットしています。以降、解説で使用しているソースコードでは、記述を一部省略しているので、実行コードを作成する場合は、必要に応じて適宜GitHub上のソースコードも参照してください。

まず、マイクロサービスとなるBackendアプリケーションのパッケージ／コンポーネント構成は以下の通りです。

なお、アプリケーション内のデータベースアクセスはSpring Data JPAを用いており、ここでは詳細な解説は行いませんが、詳細は TERASOLUNAのガイドライン「データベースアクセス（JPA編）」 を適宜参照してください。また、テストではインメモリDBであるHSQLを利用します。

また、マイクロサービスを呼び出すBFFアプリケーション(Webアプリケーションとなります)のパッケージ／コンポーネント構成は以下の通りです。

WebアプリケーションのHTMLテンプレートエンジンとしてThymeleafを使用しています。こちらも詳細な説明は割愛しますが、必要に応じて、Thymeleafの公式ドキュメントやMacchinetta Frameworkテンプレートエンジンを参照してください。

また、2つのアプリケーションで共通して使用する部品のパッケージ／コンポーネント構成は以下の通りです。

主な構成要素は、マイクロサービスから返却されるResourceクラスと、アプリケーション基盤部品ですが、ほとんどがマイクロサービスと連携する場合やテストコードの検証に必要になったために実装した共通部品です。

なお、例外の種類や考え方、SpringFrameworkを用いた例外ハンドリングの基本はTERASOLUNAガイドラインの例外ハンドリングのページや、RESTful Web Serviceの例外ハンドリングのページも参考にしてください。

次節以降のテストコード実装の解説時に、上記のいくつかのコンポーネントについては必要に応じて説明しますが、ここで示しておきたいのは、Backend/BFFともに「Controller」「Service」「Repository」がアプリケーションの中核的なコンポーネントだということです。SpringBootをベースとするアプリケーションでは、提供されているアノテーションの関係上、同じようなコンポーネント構成をとるケースがほとんどなので、以降は、Controller、Service、Repositoryに関するテストを前提として話を進めていきます。

アプリケーションのテスト観点

先述したマイクロサービス(Backend)とWebアプリケーション(BFF)のコンポーネント構成では、以下のような観点で各テストごとに品質を担保していくのがベターです。

次回以降は、上記の観点に従い、SpringBootを使って、ControllerやService、Repositoryのテストの実装方法を解説していきます。