[Playwright] 0から勉強して導入した話
はじめに
この記事では、社内PJにPlaywrightを導入した体験談 についてをまとめております。
結論
導入背景
なぜ、Playwrightを導入するようになったのか?
新規のプログラムに対しては、以前からバックエンド側でユニットテストを実施しておりました。
しかし、既存のプログラムは一部フロントエンド側で計算処理を行っていたため、満足するユニットテストを実施する事が出来なかった。
ですが、Playwrightの導入により、
既存のプログラムに対して、フロントエンド側/バックエンド側の計算処理のテストを実施することが可能になるから
良かった点
1. 各環境のテスト工数の軽減
現PJのリリースまでのテストフローは下記の通りでした。
- ローカル環境でテストを行う
- DEV環境でテストを行う
- STG環境でテストを行う
- PRD環境でテストを行う
最低でも4回同じ内容のテストを以前までは、手動手動確認で行っておりましたが、(丸一日手動テストする日もありました)
Playwright(自動化テスト)のおかげで2~4まではテストの実行結果を見守るだけになりました。
2. デグレに対するストレス軽減
Playwrightをコーディング最中にプログラムミスや意図しない挙動を発覚することがありました。
以前は、手動確認だったので1から手動確認を行っており苦労しました。
しかし、これまで作成したPlaywrightを再度実行するだけで良くなりました。
苦労した点
1. HTMLのエレメント要素がぐちゃぐちゃ
既存のプログラムは、綺麗に表示されていれば問題ないHTMLになっていました。
そのため、目的のデータを取得したいのにlabel等がなく苦肉の策でデータを取得するPlaywrightになってしまった。
2. ロード時間
各機能やページに対してロードを示すデータが異なっていたため、それらを内包する関数の作成が難しかった
また、ロード待機関数をちゃんと作成してもロード中のデータを取得しようとしundefinedでテストが失敗するケースが散見されました。
工夫した点
1. ラッパー関数を作成
Playwrightの既存関数を使用しても何も問題はないのですが、行数が増えたり、可読性が低下によって、
Playwrightが他メンバーに受け入れにくいを避けるためにシンプルなテスト攻勢を意識しました。
- await page.goto('https://www.google.com');
+ await openPage(page, 'https://www.google.com');
2. sleep時間をむやみに使わない
ページが完全に表示されるまで、多めのsleep時間を設けることでロード時間の対処することはできます。
しかし、テスト件数が何百件の場合、テスト件数 * 多めのsleep時間 = 何時間 という単位になります。
なので、sleep時間を極力使用せず、下記コードのように活用しました。
// ネットワークがアイドル状態になるのを待つ
await page.waitForLoadState('networkidle');
Discussion