circleci+cypressによるE2Eテスト導入

2 min read

参画している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を採用しました。ググった感じの評判が良く、有名なことが採用理由です。

https://docs.cypress.io/guides/overview/why-cypress

実行環境は、circle ciを採用しました。すでにcircleci上にci環境が存在したことが採用理由です。

https://circleci.com/docs/ja/

できた設計

こんな風な設計になりました。

  • github上にe2eレポジトリが単独で存在し、それと対になる形でcircleciのe2eプロジェクトが存在するような形です。
  • apiやfrontのレポジトリは、deploy完了後に、circelciのapiを利用し、e2eプロジェクト(masterブランチ)を実行します。
  • E2Eテストに失敗したら、Slackにエラー通知と、失敗した時の動画へのリンクが流れます。

全体感

cypressとcircleciが優秀なこともあり、最低限のE2E環境を構築するための工数は、1~2日でした。

また、前提として、テストにあまり工数は割けない中で用意した環境です(スタートアップフェーズのプロダクト)。
ちゃんと時間取れる状況なら、もう少しリッチな設計になっていると思います。

cypressの感想

実行もコーディングもデバッグも直感的に進められ、E2Eテストツールとして、これ以上ないくらいに使いやすいです。

また、公式ドキュメントがすごい丁寧なので、実装方針も明確に進められます。
ベストプラクティス記事が特に参考になりました。

https://docs.cypress.io/guides/references/best-practices

Discussion

ログインするとコメントできます