PlaywrightによるE2Eテストの実装

はじめに

先月、パッケージのバージョンアップ対応でRenovateによりパッケージのバージョンアップがPRで作成されるようになりました。 Cloudflareのプレビュー機能によって、マージ前に問題ないか確認することができますが、RenovateのPRごとにアクセスして動作確認をするのは面倒でした。 そこで、CIでE2Eテストを実行し、手動による動作確認を手間をなくしていきたいと思います。

フレームワークを決める

E2Eテストのフレームワークとして今回はPlaywrightを利用します。前職でちょっとだけ触ったことがあり、自分が利用するツールを一つに絞りたかったのが一番の理由です。使ったのは2020,2021年あたりだったのですが、現在npmのダウンロード数がcypressを逆転していてシェアが一番になっているのにびっくりしました。当時のplaywrightを選んだ同僚の先見の明に感嘆しました。

勉強するにあたり以下あたりを参考にしました。同じく勉強する方はご参照ください。

• Playwright
• Playwright を使用した E2E テスト (feat. Cypress)
• 【E2Eテスト】Selenium, Playwright, Cypress, Puppeteer フレームワーク比較

Playwrightのセットアップ

パッケージをインストールします。また、今回はChromiumにてテストを行います。

pnpm add -D @playwright/test
pnpm exec playwright install chromium

Configの設定は、playwright.config.tsをご参照ください。

また、.gitignoreに以下を追加しています。フォルダ名の通りキャッシュやテスト結果をコミットする必要はないでしょう。

/test-results/
/playwright-report/
/playwright/.cache/

テストケースを決める

今回は時間の都合でトップページのみ実装します。生成AIに提案していただいた観点は4つです。それぞれ以下のように考えました。

• 基本的なレイアウトとコンテンツの表示確認
  • これはその通りだと思い、ロゴ・サイト名・サイト説明文が正しく表示されているのかの3ケースを実装します。
  • 正直そこまでする必要はないかもですが、トップで表示されるべきはこの3つと考えました。
• 記事一覧の表示確認
  • 結論から言うと、articleが最大数15表示されているテストケースにしました。
  • ソートされているか、ポストカードが正しく表示されているかも提示されましたが、副次的なものでメインは記事がきちんと取得できていることだと考え却下しました。
• All Postsリンクの表示
  • こちらはメインではなく、後で実装するヘッダの動作確認ができれば問題ないので却下しました。
• レスポンシブデザインやダークモードの変更
  • こちらは見た目の問題で本質ではないので却下しました。

テストを実装

今の時代AIに書いてもらうことも多いため、playwrightの書き方をここで説明することはしません。 テストの具体的な書き方はコードや他の記事をご参照ください。

PlaywrightやCypressにはレコード機能があるのでテスト作成の補助の役に立ちます。 Playwrightの正式サイトはこちらです。VS Codeの拡張機能を用いることで実際に画面をクリックしながらテストを実装することができます。これで全て完結するわけではないですが、要素の取得の仕方の参考になります。日本語の参考記事も参考にしました。

テストを実行

以下のコマンドで実行できます。

pnpm exec playwright test
pnpm exec playwright test --ui

通常はCLIの1つ目でいいですが、UIはエラーが出た時の各動作確認などに便利です。 また、実行結果をレポートとして表示してくれるのもいい機能だと思います。

CI

Github Actionsに登録し、mainブランチへのPRの時にE2Eテストが実行されるようにします。Setting up CIにて設定する内容も記載されているので記載の通りにすれば問題ありません。

ただし、私の環境の場合、pnpmを利用しているのでインストールやキャッシュが必要になり、修正しています。修正したYAMLファイルはこちら。

PRを作成したら無事にテストが実行され、うまくいきました！

おわりに

今回は、Playwrightを利用してE2Eテストを実装しました。まだ、トップページしか実装していないのでRenovateのPR時にチェック不要とまではいきませんが、これを進めていけば楽になりそうです。

テストの実装はAIによってどんどん簡単に実装できるのかなと私は推測しています。 テストを実装している方が無意味だと言っているわけではありません。むしろその方達が持っている、テストを考慮した実装・メンテナンスコストを考慮したテストケースの設計はまだまだ通用すると思います。 個人ブログなのでメンテナンスが発生することは少ないかもしれませんが、個人ブログのE2Eテストの運用を通してその一端を感じられたらいいなと考えています。

また、今回はテストケースの考えを生成AIに頼ってしまいました。 後で気づいたのですが、SREらしくクリティカルユーザージャーニーを定義してコアな部分だけをE2Eテストするように導くべきでした。 なので次の記事はCUJにしてみようかなと思っています。

（今年の目標で宣言したRustやOpenTelemetryのことは忘れていません。裏で着々やっています。）

最後まで読んでいただきありがとうございました。