見出し画像

Playwrightを導入してみた話

iCARE QAEチーム

コニチワ。QAEチームのとよしーです。

3月はJaSST Tokyoにオフラインで参加して様々な講演と様々な方とお話できてホクホクしていた側面もあれば、プライベートでは眉毛を脱毛したり髪にパーマをあてたりして毛に対してのアプローチが多い月でした。
そんなこんなであっという間に4月。
春というかもはや初夏くらい暑いですね〜。

さて、春といえば…。
そうですよね。E2Eテストの季節がやってきましたね（違う）

最近ちょうどQAEチームでPlaywrightを導入してみたこともあったので、今回はそのことについて書いてみようかと思います。

Playwrightとは？
Microsoft社が出しているChrome、Safari、Firefoxをコマンドライン上で実行できるE2Eテストのツール

導入までのプロセス

1.Design Docsを書いてみた

なんでPlaywright導入するの？どうやって運用していくの？を他チームやCTOにも伝えられるようにドキュメントを残しておきたいと思ったので、Design Docsを書いてみることにしました。

Design Docsとは？
Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する人が作成するドキュメントです。
このドキュメントには、高レベルの実装戦略と主な設計の決定事項がまとめられており、設計において考慮されたトレードオフに重点を置いて文書化されています。

Googleの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を書くのは自分の中で思考の整理ができたので個人的にとてもおすすめです！
もしやったことない方がいればぜひチャレンジしてみてください〜





この記事が気に入ったらサポートをしてみませんか？