Cognitoのユーザプールに対するテストのモック化を辞めてテスト専用プールを作った

Goで AWS Cognitoのユーザプールに対して直接テストを実行するようにしました。

おもに利用するAPIはAdminGetUser AdminUpdateUserAttributes で、以前はオンメモリでモック書いていました。 サービスが大きくなるにつれて項目も増えていき、プロフィール関連のデータから、Stripe/プラン関連、外部アカウント連携情報などになりました。 そうすると、Cognitoの実装に間違えがあると、最悪複数の機能に影響することになり、テストの導入を検討しました。

インフラとして、様々なエミュレートサービスやOSSを検討しましたが、サービスの性質上、すべての機能を網羅することが難しいようでした。 APIごとに互換があるかどうかの検討が挟まることは、開発のスピード感を損ねてしまう可能性を残しそうでした。

そのため、実際のCognitoのユーザプールに対してテストを実行するようにしました。テストの信頼性が上がりますし、ユーザプールに対する操作である限り、何も考慮が不要のメリットは大きいと思いました。

インフラ構成がちょっと手間がかかりました。 terraformリソースに、新しい./modules/cognito/ モジュールを作成して、既存リソースはmoved、CIテスト環境用にenviromentを作成。 GitHub ActionsでのGoのテスト実行中に、該当のユーザプールの操作が可能なロールを作成。 CIのワークフローでは、go test前に、CI用のユーザプールのデプロイ(ロール必要)。

このコストがどの程度になるのかは未知で、CIの実行プロセス、またはCognitoに対するテスト設計(条件付の実行)などを考える必要があるかもです。

サービスがスタートしたばかりで、なるべくCognitoに情報を詰めることは、フロントエンドでのログインユーザの情報同期をほとんど考えなくて良いので快適でした。 今回、テストを追加して信頼できるバックエンドとなりました。開発のスピード感維持しつつ要所に堅牢なテストを導入できたのかなという総括です。