circleci+cypressによるE2Eテスト導入
参画しているSaaS系のプロダクトに、circleci + cypressで、E2Eテストを導入したので、その話。
主にはE2Eテストの動作環境/システム設計/採用技術に関して。
読者の想定
- E2Eに興味がある人
- E2Eを実務で導入したいけど、どういう設計にするか迷っている人。特にスタートアップフェーズの方。
書かないこと
□ E2Eテストやciとは何か
□ E2Eを導入する必要性
□ 具体的なツールの使い方
参画したプロダクトの状況
- SaaS系のプロダクト
- ローンチしてから3年目のまだまだスタートアップフェーズ
- フロントとバックエンドはレポジトリ（コンテナ）が分かれている
- github+circleci+awsで、すでにci/cd環境が用意されている
E2Eの導入の目的と方向性
本プロダクトにE2E導入した際の目的と方向性。
- 本プロダクトにおいては、E2Eは、予期せぬクリティカルなバグを網羅的に防ぐことが目的。
- 細かいチェックはUTに任せる。
- E2Eの責務は、フロント~インフラまで包括的に、網羅的にバグを潰すこととする。
ここから設計の話。
E2Eテストの実行/動作環境
E2Eを実施する環境について。ググった感じ、一般的には、大きく2パターンありました。
パターン① ci内で立てたコンテナ環境に対して実行
パターン② 公開環境（いわゆる検証/ステージング/本番環境のこと）に対して実行
本プロダクトでは、以下のような理由から、後者のパターン②を採用しました。
- インフラ（aws）環境を含めたチェックにしたい
- 本プロダクトは、フロントとサーバーサイドでレポジトリ（コンテナ）が違うシステムであ李、統合してci回すには一工夫必要である。
E2Eテストを走らせるタイミング/トリガー
こちらもググった感じ、一般的には大きく2パターンありました。
パターン① ciの一貫として実行。E2Eテストに失敗したら、deploy前で止まるイメージ
パターン② deploy後に実行。deploy完了をトリガーに、高度なヘルスチェックを行うようなイメージ。
本プロダクトでは、以下のような理由から、後者のパターン②を本プロジェクトでは採用しました。
- 本プロダクトには、予算の都合から検証環境が存在せず、ステージング/本番環境しか存在しませんでした。
- その中で、どうしてもステージング環境は荒れ気味になるため、E2Eの成功をリリースの必須条件にするのは融通が効かず厳しかった。
採用した技術
E2Eツールとしては、cypressを採用しました。ググった感じの評判が良く、有名なことが採用理由です。
実行環境は、circle ciを採用しました。すでにcircleci上にci環境が存在したことが採用理由です。
できた設計
こんな風な設計になりました。
- github上にe2eレポジトリが単独で存在し、それと対になる形でcircleciのe2eプロジェクトが存在するような形です。
- apiやfrontのレポジトリは、deploy完了後に、circelciのapiを利用し、e2eプロジェクト（masterブランチ）を実行します。
- E2Eテストに失敗したら、Slackにエラー通知と、失敗した時の動画へのリンクが流れます。
全体感
cypressとcircleciが優秀なこともあり、最低限のE2E環境を構築するための工数は、1~2日でした。
また、前提として、テストにあまり工数は割けない中で用意した環境です（スタートアップフェーズのプロダクト）。
ちゃんと時間取れる状況なら、もう少しリッチな設計になっていると思います。
cypressの感想
実行もコーディングもデバッグも直感的に進められ、E2Eテストツールとして、これ以上ないくらいに使いやすいです。
また、公式ドキュメントがすごい丁寧なので、実装方針も明確に進められます。
ベストプラクティス記事が特に参考になりました。
Discussion