CypressからPlaywrightに移行しました

2023年4月10日

柳龍哉

URLをコピーしました！

こんにちは、フロントエンドエンジニアのやなぎ（ @apple_yagi ）です。

先日、フロントエンドのIntegration Testで使用されていたCypressをPlaywrightに移行したので、その理由や実際に移行してみて感じたメリットなどをご紹介いたします。

なぜ移行したのか

いくつか理由はありますが、大きな理由の1つとして Cypress は並列でテストを実行することができなかったことがあります。

Cypress で書かれた Integration Test はAPIリクエストを全てモックしているため、データベースの状態などにテスト結果が左右されることがなく、全てのテストを並列で実行可能でした。しかし、Cypressは並列でテストを実行することができず、テストを直列で実行するしかなかったため、テストの完了までに時間がかかってしまう問題がありました。

それに対し、Playwrightは並列でテストを実行できるため、Cypressよりも迅速にテストのフィードバックを得られることが期待できます。

また、Playwright は単体で Visual Regression Test（以下「VRT」とする）をすることができることも理由の1つです。

PR TIMESではデザインシステムで定義したコンポーネントをMonorepoで配布し、それらを用いて開発する体制をとっています。

このような開発体制で起こる問題の1つとして、デザインシステムで定義したコンポーネントに変更を加えた際の影響範囲が大きいことがあり、変更のあったコンポーネントが使用されている箇所のデザイン崩れを人の目で全て確認するのは無理がありました。

VRT を導入すれば、その問題の解消に近づくことができると考えていましたが、Cypress を用いて VRT をするには他のライブラリと連携する必要があり、技術選定や環境構築をするなどといったコストがありました。

それに対し、Playwright は単体で VRT をすることができるので、手軽に始めることができます。

その他にも Playwright に移行することで、フロントエンドエンジニアには馴染み深い async/await でコードを記述することができることや、Codegen機能を使用して手軽にIntegration Testの作成を始めることができるといったようなメリットがあったのも移行を決めた理由です。

移行作業について

元々 Cypress で書かれていたテストケースは30個ほどしかなかったため、移行作業は1週間ほどで完了しました。

また、Playwright は Jest や Vitest にあるような expect や、React Testing Library の getByRole や getByText のような関数が用意されており、Unit Test に近い感覚でコードが書けたため、テストコードの書き方に困ることはそこまでありませんでした。

Playwrightの実行環境

Playwrightは以下のような構成で実行するようにしました。

Playwrightを実行するのはローカルの開発環境とGitHub Actionsで行い、それぞれの環境の差異をなくすためにDocker上でテストを行なっています。

Playwrightに移行してみて

テストの実行時間

Cypressで書かれていたテストケースと、同じテストケースをPlaywrightで実装し、30のテストケースを実行したところ、以下のような結果となりました。

	実行時間
Cypress	136秒
Playwright	39秒

前述した実行環境ではDocker上でPlaywrightを実行するようにしていますが、CypressはDockerを使用していなかったため、この検証ではPlaywrightでもDockerを使用せずにテストを実行しています。

テストを実行したPCのスペックは以下の通りです。

MacBook Pro
macOS Monterey
プロセッサ 2.3GHz 8コア Intel Core i9
メモリ 32GB 2667 MHz DDR4

ご覧の通り、Playwrightに移行することでテストの実行時間を136秒から39秒と大幅に短縮することができました。

注意点として、この結果は実行マシンのコア数によって大きく変わります。今回使用したPCは8コアなので、8並列でテストが実行されましたが、GitHub Actionsのようなマシンのスペックが高くない環境では並列でテストが実行されませんでした。そのため、コア数が少ない環境ではCypressとほぼ変わらない実行時間になる可能性があります。

また、Docker上でPlaywrightを実行するとDockerで使用できるリソースによって、並列度や実行速度が変わるため、今回の計測結果よりも遅くなります。

Visual Regression Test

VRTは以下のように行いました。

test('VRT', async ({ page }) => {
  await page.goto('/');
  // タイトルが表示されるか確認する
  await expect(page.getByText('タイトル')).toBeVisible();
  // VRT
  await expect(page).toHaveScreenshot('VRT.png');
});

PlaywrightでVRTを行う際には toHaveScreenshot と toMatchSnapshot という2つの関数が用意されていますが、今回は toHaveScreenshot を採用しました。

VRTはアニメーションなどの影響でFlakyになることが多々ありますが、 toHaveScreenshot は以下のような効果があり、Flakyになる要因を減らしてくれます。

This function will wait until two consecutive page screenshots yield the same result, and then compare the last screenshot with the expectation.

和訳（Deepl）
この関数は、2つの連続したページのスクリーンショットが同じ結果を返すまで待機し、最後のスクリーンショットを期待値と比較します。
https://playwright.dev/docs/api/class-pageassertions#page-assertions-to-have-screenshot-1

またVRTで使用する画像はGitで管理し、Pull Request毎にVRTが実施されるようにしています。

画像をGitで管理することでPull Request毎に画面の変化を見ることができ、レビューが捗ったり、予期せぬデザインの崩れなどを目視で確認することができます。