これは Livesense Advent Calendar 2022 DAY 20 の記事です。
はじめに
株式会社リブセンスの転職会議事業部Webエンジニアの @ishitan-liv です。
今回は、過去に転職会議でも導入しようとして挫折してきたE2Eテストについて書きます。 E2Eテストを自作するか、SaaSを使うのかで比較した結果と、Datadog Synthetics Testsの使い方を軽く紹介したいと思います。
なお、この導入については完全に個人プロジェクトとしてやっております。 リブセンスではエンジニアの権利として毎月10%の技術投資枠確保というものがあり、Googleの20%ルールのようなもので、約20日勤務だと想定して2日間は興味のある技術的なことに使えます。
- はじめに
- 導入検討経緯
- 技術選定のためにトレンド調査
- 選定候補の決定
- Datadog Synthetics Testsの使い方
- Datadog Synthetics Testsを使ってみた結果
- 今後について
このブログ記事を読むと得られる(と思われる)もの
- WebアプリケーションのE2Eテストについてちょっとわかる
- E2Eテスト大手のSaaSの検討結果
- Datadogでテストを作成する方法
- フロントエンドテストについて悩んでいる仲間が他にもいるよという安心感
今回書かないこと
アドベントカレンダーにしては規模が大きくなりすぎてしまうため、今回書かないことを明記しておきます。 このあたりはご注意ください。
- 各種ライブラリやツールなどの調査中の細かい検証結果
- 本運用にまだ至っていないため、運用効果についてはかけないこと
- 詳しい設定方法や内容など
- 一部紹介のために記載はあります
導入検討経緯
転職会議に限らずですが、多くのWebアプリケーションではフロントエンドのテストに悩んでいるチームは多いのではないでしょうか。プログラムによる機能ごとのユニットテストはあるが、サービス全体を通した統合テストは手作業で地道に確認しているなど。
転職会議の場合、サブドメインごとにマイクロサービス化されており、リポジトリ自体も分かれています。 そのため、サブドメインをまたいだテストとなるとコード上のユニットテストだけではカバーしきれないこともあり、エラーや不具合に気づけないことがあります。
そこで、現在行っているリリース前の手動テストによるコストの削減と、定期的なテスト実行による不具合の検知を目的としました。
求めている要件
あげ始めればキリがありませんが、以下の観点を中心に調査しました。
- GUIだけで直感的にテスト作成出来る
- 非エンジニア職でも修正できるとなお良い
- テスト修正の時間をあまりかけたくない
- HTML要素や構造の変更などがあっても、ある程度曖昧さがカバーされる
- サポートが途切れなさそう
- 衰退気味なライブラリやツールは除外
- ランニングコストが安い
- お金大事
特に最後に挙げたランニングコストの部分を重視しています。今回、E2Eテストを本格導入する前に、コストをあまりかけずに効果の検証を行いたいという事情がありました。
また、本格導入することになったとしても、継続的に利用するサービスである以上、ランニングコストを安く抑えられるとそれに越したことはありません。
実現したいテストケース
転職会議において重要である主要機能をカバーしたいので、一旦は以下のケースを最低限網羅出来るようにテストしました。
- ユーザーログイン機能
- ただしソーシャルログイン機能については対応してないSaaSは多い
- 自作であれば対応出来るがそこまでコストを掛けたくない
- 新規ユーザー登録機能
- 頻繁にABテストやレイアウトの微調整などが入る箇所であり、各種動線からのリダイレクト先でもあり綻びが生じやすい
- 口コミ投稿機能
- 転職会議の肝である、口コミの投稿がきちんとできるか
- 求人検索機能
- 後から気づいたが、DatadogのHTTPテストで少なくともアクセスについては担保出来ていたので異なるテストを書くことになる
- 口コミパス課金機能
- 外部サービスを経由して課金するため、定期的なテストがあると安心ではないかという観点
技術選定のためにトレンド調査
さてテスト導入とは言ったものの、何が今の主流でよく使われているのかを調べる必要があったので、簡単にですが私が調べたものを載せておきます。
※全てを網羅しているわけではなく、Qiita, Zenn, githubやGoogle検索から抜粋しています。
※個別のテストや使用感は今回は省きます。
WebDriver 系
Selenium系
- いくつか種類がありIDE用などもある
- WebdriverIO
- Nightwatch.js
- Testium
- Protractor
- Selenium Builder
- Selenium Web Driver
- Selenium Server
(ヘッドレス) ブラウザ自動化系
- Chromeless
- Puppeteer
- jsdom
- Nightmare
(ヘッドレス) ブラウザ自動化 + テスト系
- Cypress.io
- TestCafe
- Intern
- Playwright
Chrome 拡張
- Ghost Inspector
API テスト系
- Postman,
- Karate
- Pact
SaaS
- Autify
- mabl
- AirTest
- Datadog
選定候補の決定
各種ツールやサービスなど列挙しましたが、そもそも管理コストの観点から自作という考えはあまりなかったため、評判の良いAutify、mabl, Datadogの中から選定することにしました。*1
検討1: Autifyについて
- 複数ブラウザ、複数端末のテストが出来る
- よくあるクロスブラウザを手動でテストしなくてすむ
- モバイル対応している
- iPhone、Androidのそれぞれのブラウザにも対応
- jadeなどのテストでやっているDOM要素にidをつけたりしなくて良い
- ちょっとした仕様変更があったときの、テストの修正が楽
- オートヒーリング機能
- つまるところ、多少のDOM要素変化(html要素変更など)には追従してくれるらしい
- 本番に近い環境でテスト出来る
- 近いというより実際にステージング/本番を叩くことになる
- GUI操作だけでほぼ完結出来る
- 非エンジニアでもメンテナンスできる
- 属人性が生まれにくい
- プログラムがわからなくともある程度のインターネットの知識があれば使える
- プログラムソース上だとテストコードや意図を知らないと背景がわからないことが多い
- 困った時に日本法人のサポートに相談できる
- 有料のメリット
- 同じテスト(群)を本番環境、ステージング環境、プルリクエストごとの検証環境などURLを切り替えて簡単に実行できる
- 上記にあげた環境毎のテストを走らせることが出来るので新機能テストができる
検討2: Datadogについて
Autifyで出来ることはDatadogでも実現できそうでした。 が、自由度はこちらのほうが高いと言えますので違いだけ書いていきます。
テスト実行時に設定出来る項目が多い
Datadog ブラウザーテスト作成時 どこからのアクセス想定なのかを設定出来る
Datadog ロケーション設定 定期実行設定
Datadog 実行時間 エラー検知時の通知設定
Datadog エラー検知と通知先
サービス比較
それぞれのツールについて試用した内容については別途個人ブログなどで書きたいと思いますが、ひとまず結果だけ。
管理画面の使いやすさ
- Autify
- Datadog
- mabl
提供機能
- Autify
- Datadog
- mabl
メンテナンス性
- Autify
- Datadog
- mabl
お値段
- Datadog
- mabl
- Autify
Autifyが圧倒的に使いやすかったです。 mablについては実導入するまえに既に候補から外れてしまった感じですので割愛します。
今回はAutifyトライアルについてはサポート担当の方から電話があり、使用方法のレクチャーや具体的なテスト作成、2週間ほどの無料トライアルなど提供してもらったこともあり、サポートの手厚さがあったことも後押しになっていそうです。
Datadogについても営業の方に連絡をすればサポートしてくれそうではあるので、双方相談してみても良かったかなと思っています。
さて、Autifyが優勢かと思いきや、「求めている要件」に記載しております、「ランニングコスト」の部分に注目すると、お試しで数ヶ月使うにしても少し金額面では厳しそうだなと感じました。
Autifyについては、一応担当さんとの約束もあり値段は公表しませんが、全ての機能を使おうと思うと年間でそこそこのお値段です。 （金額が安いミニマムプランもありますが、それだと欲しい機能が足りないため、結果的にフルプライスのプランになる）
Datadogの場合は具体的に利用した分だけの請求となり、公式サイト上では「$12/month(1000テスト)」となっています。 つまり1ヶ月1000テストまでは使っても2000円以下に収まるくらいだよってことですね。 まぁ実際運用したら相当テストケースを作ることになりそうですし、実際には数万かかるかもしれませんがそこまでいっても年間でみても安いです。
金額が全てではないと考えていますが、まずはその効果を検証しないことには本導入するには至らないと考えての結論です。 そのため既にHTTPリクエストによる外形監視やアクセスログ管理に使っているDatadogの機能をそのまま利用することにしました。
技術選定結果
Datadog使ってみるぞい
いきなりここに飛んできた人は一応上の説明読んでくれると嬉しい。
以下からは使ってみた系のおまけなので興味ある方はどうぞ。
Datadog Synthetics Testsの使い方
さて、Datadogを選んだので使ってみた感想とスクリーンショットを交えて説明します。 公式にマニュアルがありますのでこちらを参考に進めていきます。
基本的には、画面中央上部にある「Start Recording」をクリックしアクションを記録させていくだけでOKです。
ログインテスト作ってみた
個別テスト管理画面
とりあえず完成画面から。
こんな感じで管理画面では各ステップとその結果を繋いでいきます。
各Stepの動作タイトルを見て分かる通り、フォームをそれぞれ選択して、各要素に対して値を入れます。 値については後から個別に編集することが出来ますので、まずは動作のレコーディングをすることが大事です。
またここで便利な機能として、何度も使うメールアドレスやパスワードなどはローカル変数やグローバル変数設定しておくことで簡単に呼び出せます。
パスワードについては、身内が使う管理画面だとしても画面上で表示するのはセキュリティ的に好ましくないのでスクリーンショット上では「 PRODUCTION_JOBTALK_LOGIN_PASSWORD」という変数をタグ付けして呼び出せるようにしています。
例えば新規ユーザー登録する際に同じメールアドレスだと重複登録出来ないため、以下のようにローカル変数で設定することも出来ます。
hogehoge+{{ date(0, YYYYMMDDhhmmss) }}@ドメイン名
これで現在時刻を元にかぶりにくい(同時にテストを走らせない限り)メールアドレスが作成されます。
詳細は以下を参考にしてみてください。
テスト結果画面
テスト回すとこんな感じで各ブラウザごとの結果が返ってきます。
PASSEDと緑色でついてるものが成功したケースです。 失敗するとFAILEDと赤色がつくようになります。
また、便利なのが実際にテスト際の画面キャプチャが撮られています。 これによりデザイン崩れやエラーが起きたときにどの画面でエラーが起きたのかわかりやすくなっています。
口コミ投稿テストを作ってみる
さて、次は主要機能である口コミ投稿のテストを作ってみました。
なんと「72Step」もあります！ *2
ユーザーの皆さんはこの各ステップ(アクション)を通して投稿するんですね…こういったアクションについても同時に把握できるのがE2Eテストの良いところです。
もう既にお気づきかもしれませんが、毎回ログインテストをレコーディングしてから別のアクションに移るのは大変だと思いませんか？ そう、そんなときに便利なのがサブテスト化です。 エンジニアのみなさん向けにいうと、メソッド化、ライブラリ化のようなイメージが近いでしょうか。
サブテスト化
今回はログイン部分だけを切り出してサブテスト化します。 とはいっても、アクションをきりのいい箇所まで作成したものを登録し、テスト作成時に呼び出すだけで完了です。
かんたんですね！ これを駆使すれば複雑な処理も簡単にテスト出来るようになりそうです。
Datadog Synthetics Testsを使ってみた結果
最後は駆け足になってしまいましたが、DatadogでE2Eテストを作り始めて感じたことなどを箇条書きでまとめてみます。
ここが良い
- GUI操作で直感的にテスト作成出来た
- クロスブラウザでのテストが用意
- 複数のサブドメインを跨ぐテストでもきちんとテスト作成された
- HTML要素以外にもコンテンツ(文章や画像やリンクなど)でもテスト出来るのは良い
- 値段が比較的安い
ここは気になる
- ABテストなどで動線に影響があるケースが厳しい
たとえば新規登録中に特定の条件のユーザーだけダイアログ表示させたり、別ページへリダイレクトさせる、ページ内容を変えているようなケースだと管理画面だけではif文などによる分岐対応は出来ないので難しいです。 一応、stepテストが失敗しても継続させるオプションはありますが、stepの順番がずれていくのでテストにならないです。
対応する方法としては、テスト対象の実装ロジック部分でDatadogからのアクセスの場合は特定のテストパターン固定になるように振り分けるなどの対応を入れておくようなことも考慮してあげると良さそうだなと感じました。
- 本番環境でテストするので、捨てアカウントが複数登録されてしまう
こちらはCS業務をおこなっているメンバーにあらかじめ決まったパターンのユーザー名やメールアドレスなどを共有することで回避しています。 ゴミデータが残ってしまう場合には、別途テスト終了時に該当のユーザーを削除するようなAPIを用意しておいてそれをサブテストで組み込むなどが考えられます。
今後について
ここまでお読みいただきましてありがとうございます。
技術投資枠で個人プロジェクトとして遊んだ結果、Datadog SyntheticsでE2Eテストはいけそうな感触をつかめました。今後は、事業部長や他のエンジニアメンバーと相談しながら本格採用を目指していければと思っています。
また、このようにしていきたいという連携がありまして
- Githubのプルリクエストと連携して変化に対応出来るようにしたい
- マージ前にGithub Actionsなどで呼び出すようにすると良さそう
- テスト自体をAPI経由で作成したい
- 既存テストの修正をGUIでやってしまうとどこを変えたのかわからないため、出来ればコードで記載して履歴を残していきたい
といった問題が残っておりますので、引き続き試行錯誤していく所存です。
課題を解決したい仲間を待ってるぞい
転職会議事業部は、世間一般でいうところのモダンな開発環境になりつつあるものの、今回のE2Eテストのようなテスト環境周りはまだまだ改善途中です。事業部方針としてエンジニア中心で行う技術寄りの改善策を後押しする環境があり、技術的チャレンジが行いやすい職場です。 負債解決や新しい技術やツール導入による改善に興味のある仲間を募集しています。
ではまた！
