ミツカリ社におけるDatadog SyntheticによるE2Eテストの取り組み(検討編)
※この記事は自分が所属する組織で書いた以下の記事のコピーです。投稿した記事は個人の著作物として自ブログにコピーして良いルールとしています。
https://tech-blog.mitsucari.com/entry/2025/02/17/102031
こんにちは、ミツカリCTOの塚本こと、つかびー(@tsukaby0) です。
ミツカリではDeveloper Experienceに拘っており、日々改善を行っています。CIの一環として単体テスト、インテグレーションテストを行っていますが、2022年ごろからE2Eテストも行っています。これによってSTG環境で手動でテストしてからリリースする、というような行為を減らしていますし、リグレッションテストを実現しています。
この記事ではミツカリのE2EテストとDatadog Syntheticについて説明します。
E2Eテストとは
https://circleci.com/ja/blog/what-is-end-to-end-testing/
https://zenn.dev/yuu104/articles/what-is-e2e-test
E2Eテストについては解説している記事が多いため、詳細は上記をご覧ください。
E2Eテストをやるためのツールは色々と存在します。例えば最近ではPuppeteerやPlaywrightを使用している例をよく聞きます。
ツールの選定については、以下の株式会社ココナラ まるさんの記事が参考になります。
https://zenn.dev/coconala/articles/40849ff2533f84
E2EツールはSaaSも存在します。以下は一例です。
MagicPodはWebというよりはモバイルアプリの文脈でよく聞きますね。WebではAutifyが大型の調達などの影響もあり、よく聞く気がします。
弊社では数年前にAutifyとDatadog Syntheticを比較し、主に金銭コストの理由からDatadog Syntheticを採用しました。
Datadog Syntheticの選定理由
Playwright等で自作するというのもありではありますが、私の過去の経験ではE2Eの保守コストが高く、日々シナリオの変更に追われて、結局使われなくなったというチームを何度か見たことがあります。外から見ただけというケースもありますが、私自身実際に昔Seleniumか何かを使ってメンテが辛いなと感じた記憶があります。
このことからE2E環境を専任でメンテできる人がいない今のミツカリの組織体制ではメンテコストを抑えることが最重要課題でした。
そこで、まずは自作・セルフホスティング(コードでのテスト作成)の路線ではなく、ノーコード、ローコードによるSaaSの路線を選択しました。
次にAutifyとDatadog Syntheticを比較しましたが、金銭コストの面からDatadogを選択しました。
Autifyは質は良いと思うのですが、最もミニマムなプランでも100万円/年、近くの費用がかかるようでした(※3年以上前の情報です)。最新の価格については把握できていないため、各自お問い合わせください。
Datadogの価格については公開されているため、以下をご覧ください。
https://www.datadoghq.com/ja/pricing/?product=synthetic-monitoring#products
Synthetic MonitoringのブラウザテストがE2Eです。
$15/mo/1000実行 という価格設定です。
E2Eのテストシナリオの中のステップ(assertionやページ遷移など)が25stepを超える場合は実行数2としてカウントされますが、概ね1シナリオ1実行と捉えても良いでしょう。Datadogはミニマムに始められる点が非常に魅力的です。ただし、もう一つ価格面で注意が必要で、それはテストの並列度です。
E2Eに速度(実行〜完了までの時間)を求めないのであれば問題はありませんが、速度を求める場合は追加の検討が必要です。まず、Datadogはデフォルトでは1並列でしか実行できません。テストが複数ある場合は、それらはシーケンシャルに実行されるため、それだけ完了に時間がかかります。
以下にある通り追加のアドオン( 並列テスト (アドオン) )を購入することで並列数を上げることができます。
https://www.datadoghq.com/ja/pricing/?product=continuous-testing
$98.75/moなので、それなりに高額です。
Autifyは記憶が曖昧ですが、数年前に商談させてもらったときは確か10並列がデフォルトで含まれているプラン体系でした。だからこその高額なのかもしれませんが、そのあたりを調整しての契約はできないと言われてしまいました。
最新のプライシングではStandardプランに並列実行オプションは含まれていないので、私が当時商談したときよりは安く始められる可能性はありそうですね。ただし、これは1並列なのかなと予想しています。
上記の理由からDatadogの方がミニマムに始められますし、並列度も自由に設定できるため、Datadogを選びました。並列度は一旦1で開始しつつ状況に応じて増やす方針としました。記事執筆時点では導入から3年ほど経過しましたが、現状では並列数は3としています。全てのE2Eテストの完了にはおよそ13分ほど要しています。
その他、SaaS型のE2Eツールの特徴としてある程度のアプリケーションの変更に耐性があるという点があります。例えばmablでは以下のようにオートヒーリングという機能を有しています。
https://www.mabl.com/ja/auto-healing-tests
検証はしていませんが、作成したシナリオがfailしたらアプリケーション側の変更に追随して自動でシナリオを変えてくれるのでしょう。
Autifyもそういう機能は有しているようですね。
Datadogには残念ながらシナリオを自動で変更してくれるような機能はありません。ただ、以下のような機能はあります。
使ってみての感想ですが、Datadogのアルゴリズムはなかなか優秀だという感覚があります。要素を特定するセレクタのようなアルゴリズムが優秀で、ボタンの場所を変えたり、cssのクラス名が変わったりしてもうまく要素を特定してくれているような印象があります。
そのため、多少の画面変更を行ってもテストシナリオを変更する必要はありません。
E2Eテストの注意点と作成方針
E2Eテストは単体テストよりも遅く、また高コストです。Flakyにもなりやすく、悩まされている人も多いと思います。
弊社ではテスティングトロフィーに則って、あまり作りすぎないように意識しています。テスティングトロフィーについては以下のライトコードさんの記事を御覧ください。
https://rightcode.co.jp/blogs/40957
基本方針としては単体テストをなるべく網羅的に書くようにし、単体やインテグレーションでカバーできない部分をE2Eとして用意することとしています。
毎回新しい機能開発や変更が発生するたびにE2Eテストについて追加・変更すべきかを考え、変更しない場合もあります。
テストシナリオ作成前の検討
まず作成する前に、どのような形式、タイミングでE2Eを実行するかを考えると良いです。
- 実行タイミング
- CI/CDのプロセスでdev, stg等の環境にデプロイした後で実行する
- prd環境にデプロイする前に実行する
- prd環境にデプロイした後で実行する
- 2時間ごとなど、定期的に実行する
- 対象環境
- 専用の環境を用意しておき、そこで実行する
- stg環境で実行する
- prd環境で実行する
- 結果(インシデント)に対する対応プロセス
今回は検討編ということでDatadogの採用に至るまでに考えたことなどをアウトプットしてみました。
次回の記事では実際に運用して得られた知見等を共有したいと思います。
現在、ミツカリではITエンジニアを募集しています。ミツカリでは製品開発だけでなく、Developer Experienceにも力を入れています。興味のある方はぜひお気軽にご連絡ください！