E2Eテストの運用課題を Playwright に置き換えることで解決する
参考になった
5
株式会社SmartHR / s-sasaki-0529
フロントエンドエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 101名〜300名
| ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|
| 10名以下 | 2023年11月 | B to B |
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
以前から Ruby(RSpec) + Capybara + Selenium 構成の E2E テスト基盤が運用されていました。
ツールに限らず運用プロセスや仕組み全般の問題も含みますが、旧構成の運用では以下のような課題感がありました。
テスト実行の立ち上がりが低速で、サイクルを回しづらい
旧構成では、ブラウザ自動操作のための WebDriver プロセスを間に挟む都合もあり、ローカル環境でテストを実行するたびに一定の待ち時間が発生し、トライアンドエラーのサイクルが回しづらい問題がありました。
要素セレクタの使い方などの実装が難しく不安定
旧構成では、ブラウザを自動操作するために必要な要素を取得するための手段が乏しく、自由度の高いセレクタを用いることになるため、実装者によってその実装方針がマチマチになる問題がありました。また、その自由度の高さ故に、変更に弱かったりフレーキーなテストコードになってしまうこともあり、保守性に大きな問題を抱えていました。
テスト失敗時の原因調査、修正が困難
旧構成では、定期実行している E2E テストが落ちた場合に、Allure Report によるテストレポートで結果を確認できるようになっていましたが、Allure Report では、なぜそのような失敗をしたのかの状況を整理するのが困難でした。
どのような状態を目指していたか
E2E テスト基盤を再構築することで、前述の問題を解決し、高速で安定性があり保守もしやすい E2E テストを目指しました。
ツールとして Playwright を採用したのは、その目的を達成するための一手段ではありますが、多くの問題を一度に解決することが出来ました。
関連
本レビューでは Playwright そのものに着目していますが、開発プロセス全体を含めた課題及びその解決方法についてはテックブログを公開しているので、そちらも合わせてご覧ください。 E2Eテストを Playwright で作り直して開発プロセスに組み込む話
比較検討したサービス
- Capybara + Selenium (現行)
- Cypress
- TestCafe
比較した軸
- 現状の課題を解決することができるか
- メンバーがテストコードの読み書きをしやすいか
- 今後も継続的に開発されるか
選定理由
Playwright は E2E テストの実装から運用までの全てをカバーした様々な機能が提供されています。開発も microsoft によって行われているという安心感もあり、持続的な E2E テストの運用に向いていると判断しました。
Cypress も最後まで検討しましたが、メソッドチェインをベースとした記法のクセの強さや、iframe 内でアプリケーションを動かす都合、様々な制約があること、それに並列実行の面での課題感あたりから見送りました。
導入の成果
改善したかった課題はどれくらい解決されたか
いずれの課題も概ね解消することができました。
テスト実行の立ち上がりが低速で、サイクルを回しづらい
すべてが Playwright による恩恵というわけではありませんが、WebDriver を挟まずに、Chrome DevTools Protocol を使用しているアーキテクチャの違いからも、初回起動が体感できるレベルで向上し、フィードバックサイクルを回しやすくなりました。
要素セレクタの使い方などの実装が難しく不安定
Playwright では要素取得やアサーションのための API が豊富に提供されており、特にアクセシビリティ関係の属性を使用したシンプルな記述ができるようになり、コードの読み書きが用意になりました。
テスト失敗時の原因調査、修正が困難
Playwright には組み込みのテストレポーターがあるため、すぐにそれを利用可能な上、テスト実行中の DOM の状態をシミュレートできるトレースモードや、テスト中の動画を撮影する機能なども豊富に備わっているため、調査の敷居が遥かに下がりました。
どのような成果が得られたか
旧構成と比較して、E2E テストを開発プロセスに自然になじませることができるようになり、開発者が自分事としてテストコードを書いたり、失敗したテストを調査できるようになりました。
課題感以外の思わぬ恩恵として、アクセシビリティ関係の属性による要素セレクタを積極的に利用することで、プロダクトのアクセシビリティ課題の発見及び担保に大きく貢献するという成果も得られました。
また、社内では先行しての導入となりましたが、運用が上手く行えている背景から、社内の他のプロダクト開発チームでも次々採用されるようなり、チームの垣根を超えてノウハウをシェアできる状態にまで成熟してきています。
導入時の苦労・悩み
E2Eテストの基盤を差し替えるという点では、既存のテストコードの移植を含めた大きな意思決定となったので、進め方の検討や進捗管理で苦労しました。
一方、 Playwright の導入自体の苦労はほとんどなく、公式ドキュメントに軽く目を通す程度で一通りの使い方を理解することができたため、新規で E2E テストを導入しようという場面であれば大きな苦労もなかったと思います。
導入に向けた社内への説明
上長・チームへの説明
現状の課題と、Playwright への移行によってそれがどう解決されるかのドキュメントを最初に作成し、チームに提案しました。その時点で具体的な移行プロセスやサンプルコードの準備まで済ませておき、E2Eテストのビフォーアフターを明らかにした上でディスカッションをしました。
その後はモブプログラミングの形式で E2E テストを実際に書いてみる体験をチームで行い、実際に使ってみた上で導入の合意を得ることが出来ました。
活用方法
よく使う機能
普段遣いしているオプションを紹介します。 (いくつかは設定ファイル上で設定したり、npm scripts でショートカット化したりしていますが、便宜上 CLI の表記で紹介します)
$ playwright test --headed
実際のブラウザを使用して E2E テストを実行します。
$ playwright test --trace on
トレースを有効化して E2E テストを実行します。この場合、テスト完了後のレポートで、各ステップごとの DOM の状態をシミュレートでき、デバッグが容易になります。
$ playwright test --retries 2
E2E テストでは、外部システムに依存する場合など、どうしてもフレーキーなテストが発生することがあります。その場合に、CI 上では２回まで自動でリトライし、それでも失敗する場合のみテストを落とすといった対応が可能です。
$ playwright test --workers 4 --fully-parallel
すべてのテストを並列実行の対象とし、最大４並列で実行します。
ツールの良い点
- E2Eテストに関わるあらゆる機能がオールインワンで詰め込まれている
- Microsoftで開発されているため、持続性にも期待できる
- 人気も右肩上がりであるため、情報が世の中に溢れている
ツールの課題点
- 多機能である分、情報のキャッチアップやノウハウのシェアは積極的に行う必要がある
株式会社SmartHR / s-sasaki-0529
フロントエンドエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 101名〜300名
よく見られているレビュー
株式会社SmartHR / s-sasaki-0529
フロントエンドエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 101名〜300名
レビューしているツール
目次
- 導入の背景・解決したかった問題
- 活用方法