※この記事はバックエンドエンジニアRaman Yachiによる記事『E2E Testing system for Miitel Account』を翻訳したものです。

はじめに

こんにちは、バックエンドエンジニアの谷地ラマンです。

RevCommではマイクロサービスアーキテクチャを採用しており、私はその中で認証/認可の機能を提供するAccountチームに所属しています。
ユーザーのログイン認証を処理する重要な部分であり、ここに障害が発生するとユーザーがサービスにログインできなくなる可能性があるため、可能な限り防ぎたいです。

そのための対策としては、第一に全ての機能に対応する単体テストを実装することです。
私のチームではテストフレームワークであるpytestを使用し、Pull Requestにおいて単体テストが実行されるためコミットごとの機能を保証し、あるいはバグを検出することができます。
単体テストに加えて、実際のユーザーシナリオとしての振る舞いを確認するためのシステムテストを実装しています。これは実環境のAPIエンドポイントに対してPostmanによるテスト (E2Eテスト) を実行し、レスポンスを検証しています。

この記事では私たちのE2Eテスト自動化について紹介します。

課題

テストを自動化する前は、各メンバーがローカルマシン上でE2Eテストを手動実行してデプロイ後のサービスが期待通りの動作をすることを確認していました。
しかし、例えばあるメンバーの環境では成功していたものが別のメンバーは失敗したりと、テストの動作を統一できていないことが課題でした。
結果として、テストの信頼性が低くなってしまいました。

また、開発/ステージング/本番など、環境ごとにPostmanの変数を使い分けることも面倒でした。
そこで、リリース後の不具合を検知するためにより良い方法がないかどうか検討しました。

これまでのことから、私たちの要件は次の通りです。

常に最新のアプリケーション（URL構造やインターフェース）をテストできること
非ローカル環境で実行することで、テスト結果をチーム内で共有できること
最小限の設定内容のみを必要とするシンプルな仕組み

解決策

まず最初に、Postmanによるテストの実行をAWS CodeBuildに移行しました。CodeBuildはAWS CodeDeployによるリリースの後に起動されます。
これによりテストは常に最新のアプリケーションを対象とし、かつ個人のローカル環境に依存しないプラットフォームで実行できます。

詳しく説明します。

ソースコードの修正を取り込むと、GitHub Actionsを介してCodeDeployによるデプロイプロセスが起動します。CodeDeployの正常終了をトリガーにして、CodeBuildによるE2Eテストが起動します。

CodeBuildの処理の中で、リリース直後のアプリケーションに対してAPIリクエストを実行します。
この中でPostmanのCLIツールであるNewmanを使っています。
https://learning.postman.com/docs/collections/using-newman-cli/command-line-integration-with-newman/

これによって、PostmanのテストケースをCodeBuildで実行することができます。

テストの実行結果はCodeBuildのレポートとしてアップロードされます。
CodeBuildの処理が終了すると、そのレポートを通知するLambda関数を起動します。Lambda関数はレポートをパースしてテストの結果をSlackチャンネルに送信します。

テスト結果の通知例を示します。テストの成功件数と全体件数、そしてタイムスタンプが分かります。

特定のテストケースが失敗した場合は、該当のテストケース名を添えて通知します。

ここまでで説明してきた仕組みに関するAWSのインフラ環境やテストケースのレシピはGitHubリポジトリで管理しています。
AWS環境の構成管理、変更はTerraformで管理しています。
またCodeBuildはソースプロバイダーの指定によってこのリポジトリからテストレシピを取得できるため、常に最新のテストケースでPostmanによるE2Eテストを実行できます。

これにより、ここまでで述べてきた自動テスト全体の仕組みを1つのリポジトリを管理することで完結させています。

これらのパイプラインによってCI/CDとしてバックエンドをテストできます。テストが必要になるたびに開発者の生産性を低下させることなく、信頼性の高いテストを実行できます。テストの結果をすぐに確認できて、元となった修正も簡単に追跡できます。