E2E テスト / リグレッションテスト目的で導入した playwright
参考になった
8
株式会社hacomono / mewton
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
| 利用機能 | ツールの利用規模 | 事業形態 |
|---|---|---|
E2E テスト / リグレッションテスト | 11名〜50名 | B to B B to C |
導入の背景・解決したかった問題
導入背景
ケース1
フロントエンド開発のコアな部分を切り出し、 GitHub package としてプライベート公開するライブラリとしたい要件があり
その際にテストコードをしっかり実装する必要があった。
テストコードは、テストピラミッドでいう Unit, Integration, E2E テストのそれぞれを実装したい要件があり、
Unit テストを jestで, Integration, E2E テストの実行環境として Playwright を導入した。
ケース2
QA set チーム発足に伴い、従来利用していた mabl に加えて、 開発チーム及び QA SET チーム双方実装可能な メインプロダクト用の E2E テストがほしい、という要望を受け、
E2E テスト用のアーキテクチャとして Playwright を導入した。
目指している状態
テストピラミッドの概念に則り、 Unit / Integration / E2E テストの３種が存在しておきつつ、
E2E テスト自体はランニングコストが重いので、なるべく深いテストが書かれない状態を意識しながら、
開発チーム及び QA チームにより継続的なテストコード・テストケースのメンテナンスができてることを目指した。
比較検討したサービス
- Puppeteer
- CodeceptJS
- Selenium
比較した軸
- プロダクトのコードと共通の資産を利用できるかどうか？
- 開発チーム・QAsetチームでもメンテナンス可能かどうか？
- QA SET チームは mabl も運用しているが、 コーディングによる E2E テストが追加されて混乱しないか？
- A11y の概念に則ったテストケースを実装可能か？
- OSS としての将来性
選定理由
- 他のテスティングライブラリ (jest / vitest / storybook 拡張) との親和性
- 運用が mabl と併用がしやすいかどうか
- Microsoft 製である点
導入に向けた社内への説明
上長・チームへの説明
無料のライブラリのため、相談はしておらず、アーキテクチャ周りの詳細設計をチームに共有し、意見を貰う形とした。 Playwright の選定に関しては特に反対意見もなく、スムーズに導入できた。
活用方法
切り出されたコアロジックの E2E テスト
コアロジック周辺のメンテ可能な開発メンバーが少なく、変更回数もさほど多くはないが、変更があった際の影響度が大きいため、
切り出しの際に同時に Unit Test, Integration Test, E2E Test の３種をなるべく多く実装した。
E2E Test では、実際の描画結果の正常性検査と、レンダリング結果のビジュアルリグレッションテストの２種類を実装しており、ブラウザ上で表示される見た目の変化を検知可能としている。
場合によっては、複数のビューポート (PC, Tablet, SmartPhone) でのビジュアルリグレッションテストも実施している。
QA SET チームがメンテナンスするメインプロダクトの E2E テスト
基本的には正常系のシナリオテストを実装する運用としている。
将来的にはリリース前等の特定のタイミングで自動的にテストを実行する運用を想定している。
よく使う機能
- ビジュアルリグレッションテスト
- テストコード実装
ツールの良い点
- ビジュアルリグレッションテストができる点
- テストコード実装自体も難易度が高くない点
ツールの課題点
- テスト実装にはフロントエンドエンジニアとしての開発能力を要する
- A11y の概念がプロダクトに組み込まれていないと、テストコードの実装が大変になる
株式会社hacomono / mewton
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
よく見られているレビュー
株式会社hacomono / mewton
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
レビューしているツール
目次
- 導入の背景・解決したかった問題
- 活用方法