Playwrightを導入してみた話
コニチワ。QAEチームのとよしーです。
3月はJaSST Tokyoにオフラインで参加して様々な講演と様々な方とお話できてホクホクしていた側面もあれば、プライベートでは眉毛を脱毛したり髪にパーマをあてたりして毛に対してのアプローチが多い月でした。
そんなこんなであっという間に4月。
春というかもはや初夏くらい暑いですね〜。
さて、春といえば…。
そうですよね。E2Eテストの季節がやってきましたね(違う)
最近ちょうどQAEチームでPlaywrightを導入してみたこともあったので、今回はそのことについて書いてみようかと思います。
導入までのプロセス
1.Design Docsを書いてみた
なんでPlaywright導入するの?どうやって運用していくの?を他チームやCTOにも伝えられるようにドキュメントを残しておきたいと思ったので、Design Docsを書いてみることにしました。
具体的な中身はお見せできませんが、下記のような項目でまとめていきました。
作成者の名前
Playwright導入の目的
Playwright導入の背景
料金体系
トレードオフ (Why not?: なぜ別の方法にしなかったのか?)
設計、アーキテクチャ
Small inで実現できる案
テストデータの運用案
Playwrightで何を担保するか
メンバー (担当者やレビュワー)
セキュリティやプライバシーについての考察
今後の展望
これらをまとめた上で、他チームとCTOにDesign Docsのレビュー依頼を投げました。
2. チームでモブプロ形式で導入手順を踏んだ
週に1時間予定を立ててチームメンバーとPlaywrightに関するモブプロを実施しました。
Playwrightのインストールするまでにもyarnをインストールするのに苦戦したりなど、一筋縄ではいかない場面もありましたが、無事Playwrightのプロジェクトを作成するところまで辿りつくことができました。(パチパチ)
3. E2Eテストを試験的に1つ書いてみた
試しにログインできるかどうかのE2Eテストをチームメンバーと書いてみました。
ノーコードのE2Eテストツールとは違って、Playwrightはコードを書く必要がありますが、PlaywrightにはTest Generator機能が備わっていてこれが大変便利です!あまりの便利さに鼻血が出そうでした。
yarn playwright codegen "テストしたいURL"
というコマンドを打つと、テストしたいURLの画面が開くので、あとはテスト手順をポチポチすれば裏でコードが生成されます。
あとはコピペして任意でリファクタリングすれば出来上がり…。
便利な時代になったもんです。
ちなみにテスト実施したい場合は
yarn playwright test
テスト実施結果が見たい場合は
yarn playwright show-report
でレポートを出力することもできます。
またレポートに実施時のビデオも出力して欲しい場合は、playwright.config.ts内で
video: "on",
を設定すればOKです。
今後の悩み
Playwrightでの全能感をぐっとこらえること
Playwrightを使って日々のリグレッションテストをたくさん置き換えたい気持ちもとてもあるのですが、一方で運用コストのことも懸念点としてあがっています。
例えばE2Eテストを実施した際に「今週は30個もFailしてる」となったときに、すぐに調査&修正の時間とリソースは割けそうかどうか?
すぐに修正するのが理想ではありますが、もし放置してしまうと
「このテストはエラーでもOKなんだよね」という状態を生み出しかねません。
そうなるとE2Eテストの信頼性が揺らぎ始めます。
なので、いきなりたくさんE2Eテスト書くぞという気持ちをぐっとこらえて
「E2Eテストでなにを担保すべきか」
を合意形成する必要がありそうです。
いまのところ考えているのは
1. 既存のE2Eテストツールのテストの置き換え
2. CUJ(Critical User Journey)相当の正常系
です。
このへんは他社事例とかもヒアリングしてみたいです。
まとめ
以上、Playwrightを導入してみた話でした!
まだ具体的なテストは全然書けていない状況なのでほんと序章の序章といった感じなのですが、いままで持っていたE2Eテスト関連の課題も解消できる可能性があるのでじっくり進めていこうと思います。
あ、あと何か導入する際はDesign Docsを書くのは自分の中で思考の整理ができたので個人的にとてもおすすめです!
もしやったことない方がいればぜひチャレンジしてみてください〜
この記事が気に入ったらサポートをしてみませんか?