📘3年目、3回目のPlaywright記事を書く

[[📒Articles]] > [[📒2022 Articles]] ![[2022-10-30.jpg|cover-picture]] Webフロントエンドの[[E2Eテスト]]に欠かせない[[Playwright]]について、2022年現在の最新情報を踏まえて手引きの記事を書いてみました。 ## はじめに私が[[Playwright]]の記事を初めて書いたのはおよそ2年前、2020年の12月です。 <div class="link-card"> <div class="link-card-header"> <img src="https://avatars1.githubusercontent.com/u/9500018?s=460&v=4" class="link-card-site-icon"/> <span class="link-card-site-name">MAMANのITブログ</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Playwrightでe2eテストを書いてみた</p> </div> <div class="link-card-description"> Playwrightを使って、Togowlのe2eテストを書いてみました。 </div> </div> <img src="https://blog.mamansoft.net/images/cover/2020-12-20.jpg" class="link-card-image" /> </div> <a href="https://blog.mamansoft.net/2020/12/20/playwright-realtime-e2e-web-test/"></a> </div> 当初は今ほどシステムが整備されてなく、[[Playwright]]はブラウザ操作がメインの仕事でした。テストを書くには[[Jest]]と連携するため別のライブラリが必要で、いくつかの設定ファイルが必要で苦戦した思い出があります。その点は翌年の2021年に解消され、それを含めた別の[[Playwright]]記事を書いています。諸事情によりここでは紹介できませんが、もしかしたら知らずのうちにご覧になっているかもしれません。当時は先進的だった[[Playwright]]も、昨今では仕事で普及させるフェーズに入るほど知名度が上がってきました。ただ、[[Googleトレンド]]では[[Cypress]]や[[Selenium]]の方が上です。 ![[Pasted image 20221030130251.png]] 一方、[[GitHub]]のスター数は[[Playwright]]がトップです。(2022-10-30現在) | リポジトリ | スター数 | | --------------------------------------------------------------- | -------- | | [microsoft/playwright](https://github.com/microsoft/playwright) | 43.9k | | [cypress-io/cypress](https://github.com/cypress-io/cypress) | 41.3k | | [SeleniumHQ/selenium](https://github.com/SeleniumHQ/selenium) | 25k | 個人的には、開発する人であれば[[Playwright]]が一番使いやすいと思っているので、この結果は納得です。逆に非開発者にとって、[[Playwright]]は敷居が高いと感じられるかもしれません。そんな[[Playwright]]を今一度しっかり学習する意味でも、この記事を書くことにしました。なお、[[Playwright]]を使うべき理由の説明は割愛します。 ## テスト対象プロジェクトの作成テスト対象の簡単なWebページを作成します。ここを作りこむつもりはないので、最もシンプルに書けるであろう[[Svelte]]を使います。 ```console npm create vite@latest playwright-svelte-sample -- --template svelte-ts cd playwright-svelte-sample npm i npm i --save-dev prettier-plugin-svelte prettier ``` 余計なファイルがあると気が散るので、必要なもの以外は削除します。 ```console rm -rf public src/lib src/assets ``` 最終的に以下のファイルだけ残します。 ```ls  . ├──  index.html ├──  package-lock.json ├──  package.json ├──  README.md ├──  src │ ├──  app.css │ ├──  App.svelte │ ├──  main.ts │ └──  vite-env.d.ts ├──  svelte.config.js ├──  tsconfig.json ├──  tsconfig.node.json └──  vite.config.ts ``` `App.svelte`を以下のように書き換えます。 ```html <script lang="ts"> let count = 0; </script> <main> <h1>Playwright Svelte Sample</h1> <h2>Push "Increment/Decrement" button</h2> <div style=" justify-content: center; gap: 10px;"> <button on:click={() => count++}>Increment</button> <button on:click={() => count--}>Decrement</button> </div> <div data-test-id="counter" style="font-size: 200%; padding: 30px;"> <span>Count:</span> <span>{count}</span> </div> </main> ``` クリックするとカウントが増えたり減ったりするシンプルなページです。起動して動作を確認します。 ```console npm run dev ``` ![[2022-10-30-13-22-12.gif]] ## [[Playwright]]のインストール公式ドキュメントからお好みのインストール方法を選択します。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Installation | Playwright</p> </div> <div class="link-card-description"> Playwright Test was created specifically to accommodate the needs of end-to-end testing. Playwright ... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/intro"></a> </div> 私は[[npm]]でインストールしました。先ほど作成した[[Svelte]]プロジェクトの中でコマンドを実行します。 ```console $ npm init playwright@latest √ Where to put your end-to-end tests? · tests √ Add a GitHub Actions workflow? (y/N) · false √ Install Playwright browsers (can be done manually via 'npx playwright install')? (Y/n) · true ``` [[Playwright]]で使うブラウザをインストールしたことない場合は、それらのダウンロードが行われるため少し時間がかかります。インストールが完了したらテストを実行して動作確認します。 ```console $ npx playwright test Running 3 tests using 3 workers 3 passed (6s) To open last HTML report run: npx playwright show-report ``` なお、バージョンは`1.27.1`です。 ```console $ npx playwright --version Version 1.27.1 ``` > [!info] [[VSCode]]で[[Playwright]]を使う方法 > 最近は[[VSCode]]で使える[[Playwright Test for VSCode]]という便利なものがあります。[[VSCode]]、[[Playwright]]を開発している[[Microsoft]]の開発なので信頼性も抜群ですね。 > > <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Getting started - VS Code | Playwright</p> </div> <div class="link-card-description"> Playwright Test was created specifically to accommodate the needs of end-to-end testing. Playwright ... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/getting-started-vscode"></a></div> > > ただ、私の環境 ([[Windows 10]]) では一部の機能が使えなかったり、[[CLI]]の方が機能も豊富で困ることもないといった理由から、本記事では触れないことにしました。 > > [!add] #2022-11-21 追記 > > [[Playwright Test for VSCode]]のv1.0にて[[Windows 10]]でも一通り機能が動くようになりました。エディタ上でコードをデバッグできるので、用途によって使い分けるのがよさそうです。 ## [[Playwright]]の設定ファイル `playwright.config.ts`が設定ファイルです。テストに必要な設定のほとんどをここでカスタマイズ可能です。詳細は公式ドキュメントをご覧ください。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Configuration | Playwright</p> </div> <div class="link-card-description"> Playwright Test provides options to configure the default browser, context and page fixtures. For ex... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/test-configuration"></a> </div> あとで何度か設定変更することになりますが、タイムアウト30秒は長いので、あらかじめ5秒に変更しておきます。 ```diff - timeout: 30 * 1000, + timeout: 5 * 1000, ``` あと、毎回3つのブラウザで確認するのも無駄なので[[Chromium]]以外をコメントアウトします。実際のプロダクトでテストする場合は、必要なものをすべて選びましょう。 ```diff projects: [ { name: 'chromium', use: { ...devices['Desktop Chrome'], }, }, - { - name: 'firefox', - use: { - ...devices['Desktop Firefox'], - }, - }, - - { - name: 'webkit', - use: { - ...devices['Desktop Safari'], - }, - }, + // { + // name: 'firefox', + // use: { + // ...devices['Desktop Firefox'], + // }, + // }, + // + // { + // name: 'webkit', + // use: { + // ...devices['Desktop Safari'], + // }, + // }, ``` ## [[Locator]]で要素を特定する [[E2Eテスト]]ツールと言えば、真っ先に紹介される知識が『操作』と『アサーション』だと思います。しかし、本記事では先に[[Locator]]について説明します。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Locators | Playwright</p> </div> <div class="link-card-description"> Locator]s are the central piece of Playwright's auto-waiting and retry-ability. In a nutshell, locat... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/locators"></a> </div> 公式ドキュメントから引用した[[Locator]]の説明は以下の通りです。 > Locators are the central piece of Playwright's auto-waiting and retry-ability. In a nutshell, locators represent a way to find element(s) on the page at any moment. Locator can be created with the page.locator(selector[, options]) method. ざっくり言うと、GUI上のピースを特定する手段/方法です。『操作』にしろ『アサーション』にしろ『対象』は必要です。たとえば、あるボタンをクリックするなら、『●●ボタンをクリック』というコードを記述します。リストに表示された文字列をアサートするなら、『●●リストにxxxと表示されていることを確認』というコードを記述します。上記の『●●ボタン』や『●●リスト』にあたるものが[[Locator]]です。 [[Locator]]は`page.locator(セレクタ)`という形で作成します。`App.svelte`のケースで例を挙げてみましょう。 ```html <main> <h1>Playwright Svelte Sample</h1> <h2>Push "Increment/Decrement" button</h2> <div style="justify-content: center; gap: 10px;"> <button on:click={() => count++}>Increment</button> <button on:click={() => count--}>Decrement</button> </div> <div data-test-id="counter" style="font-size: 200%; padding: 30px;"> <span>Count:</span> <span>{count}</span> </div> </main> ``` `Incrementボタン`と`カウンター`の[[Locator]]は以下のように表現できます。 ![[Pasted image 20221030155444.png]] `page.getByText(/^Increment$/)`は『`^Increment

の正規表現を含むテキストをもつ要素』を意味します。つまり、『`Increment`とテキストが完全一致する要素』のことを指し、それが`Incrementボタン`となります。 `page.locator(':right-of(:text("Count:"))')`は『`Count:`を含む要素の右側の要素(近い順)』を意味します。それは`<span>{count}</span>`を意味します。[[DOM]]の構造ではなく、**画面上の見た目(配置座標)から相対的に要素を特定できる**ため、`カウンター`のように特定が難しい要素の[[Locator]]を作成する場合に便利です。 ## テスト作成時に使う実行オプション [[Locator]]について学んだので、`Incrementボタン`をクリックするコードを書いて、[[Playwright]]で実行してみましょう。`tests/example.spec.ts`を以下のように変更します。 ```ts import { test, expect } from "@playwright/test"; test("Test App.svelte", async ({ page }) => { await page.goto("localhost:5173"); // IncrementボタンのLocator作成 const incrementButton = page.getByText(/^Increment$/); // Incrementボタンをクリック await incrementButton.click(); // すぐ閉じないように5秒待つ await page.waitForTimeout(5000); } ``` ブラウザの操作は非同期処理になるため、`await`キーワードが必須です。付け忘れてもエラーにはなりませんので注意してください。(処理の完了を待たずに次の処理を移りたい場合除く) テストを実行してみます。 ```console npx playwright test ``` これは成功すると思います...が、本当にうまくいっているのか不安になりますよね。テスト開発時に使える実行オプションを紹介します。 ### ヘッドレスモードを無効にして実行 `--headed`オプションを指定して実行すると、ブラウザの操作が画面上で確認できます。 ```console npx playwright test --headed ``` クリックは一瞬なので肉眼での確認は難しいと思います...が、カウンターが1になり、5秒経ってから終了することを確認できると思います。 ### デバッグモードヘッドレスモードを無効にすることで、操作の様子は分かります。ただ、テストコードが間違っている場合に何が問題なのかを調べることは困難でしょう。`waitForTimeout`を適宜入れて、[[Chrome devtools]]を開いて...などとやっていては日が暮れてしまいます。 `--debug`オプションを指定して実行すると、1行ごとにステップオーバーしてテストを実行できるようになります。 ```console npx playwright test --debug ``` 起動と同時に`--headed`のとき同様、ブラウザが表示されます。加えて、[[Playwright Inspector]]と呼ばれるウィンドウが表示されます。[[Playwright]]用の簡易的な[[Chrome devtools]]みたいなものです。 ![[Pasted image 20221030161546.png]] 1行ずつステップオーバーして状況を確認できるため、テストが期待通り動作しない場合のデバッグにとても便利です。 ![[Pasted image 20221030162339.png]] また、Exploreは[[Locator]]を取得するためのセレクタ (`page.locator(セレクタ)`) を指定することで、対象となる要素をその場で確認できます。 ![[Pasted image 20221030162521.png]] 上記の例では『`Increment`が含まれる要素』を取得するため、ページ内で2つの要素が[[Locator]]の候補となります。デフォルトでは[[Locator]]の候補となる要素が2つ以上存在する場合、テストが失敗して終了します。なぜなら、それは本来、1つの要素が特定されることを期待しているからです。これは、`Incrementボタン`の[[Locator]]を作成する際、`page.getByText("Increment")`と書かなかった理由です。他のオプションは公式ドキュメントをご覧ください。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Running Tests | Playwright</p> </div> <div class="link-card-description"> You can run a single test, a set of tests or all tests. Tests can be run on one browser or multiple ... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/running-tests#debugging-tests"></a> </div> ## アサーションで結果を確認するこれまではブラウザの自動操作に関することを紹介してきました。ここからは操作結果が期待通りからを確認する方法、アサーションについて紹介します。 `tests/example.spec.ts`を以下のように変更します。 ```ts import { test, expect } from "@playwright/test"; test("Test App.svelte", async ({ page }) => { await page.goto("localhost:5173"); const incrementButton = page.getByText(/^Increment$/); await incrementButton.click(); // 『Count:』という文字を含む要素より右側にある要素をLocatorとして取得 const counter = page.locator(':right-of(:text("Count:"))'); // カウンターのテキストが1と一致するか確認 await expect(counter).toHaveText("1"); } ``` `expect(counter).toHaveText("1")`の部分がポイントです。[[Locator]]が示す要素のテキスト部分が`1`と一致するかを確認しています。 ![[Pasted image 20221030164048.png]] 今回は期待通りなので、テストは成功します。アサーションに使えるメソッドは沢山ありますので、詳細は公式ドキュメントをご覧ください。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Assertions | Playwright</p> </div> <div class="link-card-description"> Playwright Test uses expect library for test assertions. This library provides a lot of matchers lik... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/test-assertions"></a> </div> また、`expect`の前に`await`を付け忘れると期待通り動作しません。エラーも出ないためハマりやすいポイントとなっています。詳細は[[📝PlaywrightのtoHaveTextが期待通り動かない]]もご覧ください。 <div class="link-card"> <div class="link-card-header"> <img src="https://publish-01.obsidian.md/access/35d05cd1bf5cc500e11cc8ba57daaf88/favicon-64.png" class="link-card-site-icon"/> <span class="link-card-site-name">minerva.mamansoft.net</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">📝PlaywrightのtoHaveTextが期待通り動かない - Minerva</p> </div> <div class="link-card-description"> 📝PlaywrightのtoHaveTextが期待通り動かない - Minerva </div> </div> <img src="https://publish-01.obsidian.md/access/35d05cd1bf5cc500e11cc8ba57daaf88/Notes/attachments/minerva-image.webp" class="link-card-image" /> </div> <a class="internal-link" data-href="📝PlaywrightのtoHaveTextが期待通り動かない" ></a> </div> ## HTMLレポートでテスト結果を確認するデフォルトでは、[[Playwright]]のテストが失敗すると自動で[[HTML]]レポートが表示されます。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Reporters | Playwright</p> </div> <div class="link-card-description"> Playwright Test comes with a few built-in reporters for different needs and ability to provide custo... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/test-reporters#html-reporter"></a> </div> たとえば、先ほどのテストコードの期待値を変更してみましょう。 ```ts import { test, expect } from "@playwright/test"; test("Test App.svelte", async ({ page }) => { await page.goto("localhost:5173"); const incrementButton = page.getByText(/^Increment$/); await incrementButton.click(); const counter = page.locator(':right-of(:text("Count:"))'); // 実際は1だが、77にしてわざと失敗させる await expect(counter).toHaveText("77"); } ``` テストを実行します。 ```console npx playwright test ``` 失敗すると同時に、ブラウザで以下のようなレポートが出力されます。 ![[Pasted image 20221030164934.png]] テストコードに対して、以下のような情報が出力されています。 - どの行を実行したか - どの行にどれくらい時間がかかったか - どこで失敗したか - 失敗した場合に期待値と実際の値はそれぞれどうだったか今回はテストが1つしかありませんが、複数の構造化されたテストを実行した場合、それに沿ったUIとなります。コンソールよりも直感的で分かりやすいですね。 ## [[Trace Viewer]]で失敗の理由をピンポイントに調べる [[#デバッグモード]]は便利ですが、テスト変更中ではなくCIなど定常的なテストでは使用できません。一方、そのようなときに失敗してから、ローカルで[[#デバッグモード]]にて確認するのも面倒です。そんなときは[[Trace Viewer]]が便利です。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Trace Viewer | Playwright</p> </div> <div class="link-card-description"> Playwright Trace Viewer is a GUI tool that lets you explore recorded Playwright traces of your tests... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/trace-viewer-intro"></a> </div> ### ローカルで実行する場合 `--trace on`オプションをつけて実行します。 ```console npx playwright test --trace on ``` テストに失敗して[[#HTMLレポート]]が表示されると、[[Trace Viewer]]の導線が追加されています。 ![[Pasted image 20221030165925.png]] 画像をクリックすると[[Trace Viewer]]が起動します。各ステップの記録が`Actions`に記録されていますので、クリックするとその時の画面と情報を閲覧できます。 ![[Pasted image 20221030170057.png]] ### CIで実行する場合 `--trace on`オプションは便利ですが、通常のテスト実行に比べて時間がかかります。結果がすべてOKの場合、[[Trace Viewer]]の確認は不要なため無駄が生じてしまうでしょう。かといって、問題が起こってから`--trace on`で実行するのスマートとは言えません。 [[Playwright]]ではこれを見越して、`playwright.config.ts`に以下のような設定がされています。 ```ts retries: process.env.CI ? 2 : 0, . . use: { . . trace: "on-first-retry", }, ``` これは、**CIのときだけ、失敗しても2回までリトライを行い、1回目のリトライのみトレースを有効にする** という意味です。これなら、結果がすべてOKのときでもデメリットはありません。実際にCIで実行した[[#HTMLレポート]]を見てみましょう。1回目のテスト結果には[[Trace Viewer]]への導線がありません。 ![[Pasted image 20221030170805.png]] 1度目のリトライのみ、[[Trace Viewer]]への導線が存在します。 ![[Pasted image 20221030170843.png]] ## APIレスポンスをすり替える Webアプリケーションの[[E2Eテスト]]を行う上で、最も厄介な問題の1つが、テスト用にAPIレスポンスをどうすり替えるかということでしょう。テスト実行時のアプリケーション起動コマンドに環境変数を渡し、プロダクションコードの中でそれを分岐して[[スタブ]]や[[フェイク]]を使う方法もあります。ただ、それらはプロダクションに不要なコードであるため好ましくありません。幸いなことに、[[Playwright]]にはNetworkレイヤーに介入してリクエストやレスポンスを操作する機能があります。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Network | Playwright</p> </div> <div class="link-card-description"> Playwright provides APIs to monitor and modify network traffic, both HTTP and HTTPS. Any requests th... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/network"></a> </div> ### テスト対象プロジェクトの変更この機能を使うため、`App.svelte`をAPIリクエストを伴うページに変更します。APIのエンドポイントは[[Reqres]]を使わせていただきました。 ```html <script lang="ts"> interface Member { id: number; email: string; first_name: string; last_name: string; avatar?: string; } let members: Member[] = []; const fetchMembers = async () => { const res = await fetch("https://reqres.in/api/users?page=2"); members = (await res.json()).data; }; </script> <main> <h1>Playwright Svelte Sample</h1> <h2>Push "Increment/Decrement" button</h2> <h2>Click to fetch members</h2> <button on:click={fetchMembers}>Fetch members</button> <div style="text-align: left"> <ul data-test-id="member-list"> {#each members as member} <li>{member.first_name} {member.last_name}</li> {/each} </ul> <pre class="json">{JSON.stringify(members, null, 2)}</pre> </div> </main> <style> .json { background-color: darkslategray; color: whitesmoke; padding: 10px; } </style> ``` ボタンをクリックすると[[Reqres]]からユーザー情報を[[JSON]]で取得し、上に箇条書きとして、下に生データとして表示するページです。 ![[2022-10-30-18-59-07.gif]] ### レスポンスを書き換えるそれでは[[Reqres]]のAPIレスポンスに介入して、テスト用のデータにすり替えてみましょう。まずはテスト用のデータを定義します。真面目にやるなら以下のリクエスト結果を模倣する必要があります。 https://reqres.in/api/users?page=2 ただ、今回のテスト対象プロジェクトで利用しているデータは一部であるため、不要なデータはすべてカットします。このあたりの判断は、その時々の要件によって変わりますので、絶対的な正解はないと思っています。今回は以下のようなダミー[[JSON]]を用意しました。 ```json { data: [ { first_name: "たろう", last_name: "手素と", }, { first_name: "じろう", last_name: "手素と", }, ], } ``` `tests/example.spec.ts`を書き換えます。初めて登場する概念にはコードコメントを入れています。 ```ts import { test, expect } from "@playwright/test"; test("Test App.svelte", async ({ page }) => { // URLの最後が /api/users?page=2 の場合にステータス200でbodyのstringを返す await page.route("**/api/users?page=2", (route) => route.fulfill({ status: 200, body: JSON.stringify({ data: [ { first_name: "たろう", last_name: "手素と", }, { first_name: "じろう", last_name: "手素と", }, ], }), }) ); await page.goto("localhost:5173"); // 『Fetch members』とテキストが一致するボタンをLocatorとして取得し、クリック const fetchButton = page.getByRole("button", { name: "Fetch members" }); await fetchButton.click(); // data-test-id=member-list のDOMをLocatorとして取得 const list = page.locator("data-test-id=member-list"); // listに『たろう』という文字列が含まれていることを確認 await expect(list).toHaveText(/たろう/); // listに『じろう』という文字列が含まれていることを確認 await expect(list).toHaveText(/じろう/); } ``` [[#デバッグモード]]で実行してみます。 ```console npx playwright test --debug ``` ちゃんとレスポンスが書き換わっていることを確認できました。 ![[Pasted image 20221030193132.png]] この機能を使えば、プロダクションコードに[[テストダブル]]を仕込むのに比べて遥かにテストの作成ハードルが下がるでしょう。何しろ、プロダクションコードの実装が[[モック]]や[[スタブ]]を使うに困難な設計となっていても関係ないのです。レガシーコードに悩まされている開発者にとっては正直僥倖だと思います。とはいえ、テストのために必要なデータを設計し、それをテストコードに実装することだけでもかなりの労力だと思います。成熟したプロダクトに対してレスポンスのすり替えを実施しようとしても、必要なリクエストの多さに挫折してしまうと思います。そうならないためにも、普段からAPIリクエストを追加したときは、テスト用のデータを設計/定義し、[[Playwright]]のテストコードとして利用する習慣をつけるのがいいでしょう。初めからコツコツやっていれば、1回あたりの手間はそこまでではありません。何より既存コードにテストがちゃんと書かれていれば、後からjoinした開発者がテストをすっぽかすことへの抑止力にもなります。 ## [[Page Object Model]]でメンテナンスコストを下げる中規模以上のプロジェクトではテストのメンテナンスコストが高くなりやすいです。特にUI変更時や[[UIフレームワーク]]更新時に[[DOM]]構成が変わったとき、今まで取得できた[[Locator]]が取得できなくなることは多々あります。 [[Page Object Model]]はそのようなユースケースに使えると考えています。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Page Object Models | Playwright</p> </div> <div class="link-card-description"> Large test suites can be structured to optimize ease of authoring and maintenance. Page object model... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/pom"></a> </div> これは`page`オブジェクトをラップして、高レベルのIFを提供します。先ほどの`tests/example.spec.ts`を使って、[[Page Object Model]]の設計を導入してみましょう。導入前のコードは以下のようになります。 ```ts import { test, expect } from "@playwright/test"; test("Test App.svelte", async ({ page }) => { await page.route("**/api/users?page=2", (route) => route.fulfill({ status: 200, body: JSON.stringify({ data: [ { first_name: "たろう", last_name: "手素と", }, { first_name: "じろう", last_name: "手素と", }, ], }), }) ); await page.goto("localhost:5173"); const fetchButton = page.getByRole("button", { name: "Fetch members" }); await fetchButton.click(); const list = page.locator("data-test-id=member-list"); await expect(list).toHaveText(/たろう/); await expect(list).toHaveText(/じろう/); } ``` ### [[Locator]]レベルでwrapするたとえば、以下のようなコードになります。 ```ts import { test as base, expect } from "@playwright/test"; import type { Locator, Page } from "@playwright/test"; class MainPage { constructor(public page: Page) {} async setUsersJsonStub(response: Object) { await this.page.route("**/api/users?page=2", (route) => route.fulfill({ status: 200, body: JSON.stringify(response), }) ); } async goto() { await this.page.goto("localhost:5173"); } get fetchButton(): Locator { return this.page.getByRole("button", { name: "Fetch members" }); } get userList(): Locator { return this.page.locator("data-test-id=member-list"); } } const test = base.extend<{ mainPage: MainPage }>({ mainPage: async ({ page }, use) => { const mainPage = new MainPage(page); await mainPage.goto(); // デフォルトはこれ. 上書きが必要ならtest関数の中でoverrideする await mainPage.setUsersJsonStub({ data: [ { first_name: "たろう", last_name: "手素と", }, { first_name: "じろう", last_name: "手素と", }, ], }); await use(mainPage); }, }); test("Test App.svelte", async ({ mainPage }) => { await mainPage.fetchButton.click(); await expect(mainPage.userList).toHaveText(/たろう/); await expect(mainPage.userList).toHaveText(/じろう/); }); ``` コード行数は増えましたが、テストコードは3行まで短縮され、何をやっているかも自明になりました。今回の記事では触れませんでしたが、`test`の第2引数に含まれる`mainPage`はfixturesを使っています。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Advanced: fixtures | Playwright</p> </div> <div class="link-card-description"> Playwright Test is based on the concept of test fixtures. Test fixtures are used to establish enviro... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/test-fixtures"></a> </div> > [!note] > 今回はすべて`example.spec.ts`に書いてしまいましたが、[[Page Object Model]]用のクラスは別ファイルに定義した方がいいと思います。 ### 非エンジニアでもメンテ可能なレベルまで作りこむ個人的には、[[#Locator レベルでwrapする]]くらいが可読性とメンテナンス性のバランスがいいと思っています。しかし、普段ソースコードを読まない人にテストコードのメンテナンス、特にテストケースの作成をお願いする場合は別です。さらにインターフェースのレベルを上げ、英語の代わりに日本語を使うという選択肢もあります。 ```ts import { test as base, expect } from "@playwright/test"; import type { Locator, Page } from "@playwright/test"; class メインページ { constructor(public page: Page) {} private get フェッチボタン(): Locator { return this.page.getByRole("button", { name: "Fetch members" }); } private get ユーザーリスト(): Locator { return this.page.locator("data-test-id=member-list"); } async setUsersJsonStub(response: Object) { await this.page.route("**/api/users?page=2", (route) => route.fulfill({ status: 200, body: JSON.stringify(response), }) ); } async 開く() { await this.page.goto("localhost:5173"); } async フェッチボタンをクリック() { await this.フェッチボタン.click(); } async ユーザーリストにテキストが含まれることを確認(テキスト: string) { await expect(this.ユーザーリスト).toHaveText(new RegExp(テキスト)); } } const test = base.extend<{ mainPage: メインページ }>({ mainPage: async ({ page }, use) => { const 対象ページ = new メインページ(page); await 対象ページ.開く(); // デフォルトはこれ. 上書きが必要ならtest関数の中でoverrideする await 対象ページ.setUsersJsonStub({ data: [ { first_name: "たろう", last_name: "手素と", }, { first_name: "じろう", last_name: "手素と", }, ], }); await use(対象ページ); }, }); test("メインページのテスト", async ({ mainPage: 対象ページ }) => { await 対象ページ.フェッチボタンをクリック(); await 対象ページ.ユーザーリストにテキストが含まれることを確認("たろう"); await 対象ページ.ユーザーリストにテキストが含まれることを確認("じろう"); }); ``` 普段英語を使わない人に対しての可読性は上がったかもしれません。言語については、それぞれの環境に適したものを選択するのが良いと思います。その意味では好みでしょう。一方、[[Locator]]以外の処理、特に`expect`を[[Page Object Model]]のクラスに押し込むのは意味合いが違います。確認方法を気にしなくていい反面、**[[#デバッグモード]]や[[Trace Viewer]]での呼び出しコード位置が分かりにくくなる**という欠点があります。 [[Trace Viewer]]に関しては、スタックトレースから`test`関数内の呼び出し元も辿れます。しかし、[[#デバッグモード]]については、私が試した限りそれを知る方法はありませんでした。以上から、テストを書くのが開発者だけであれば、[[#Locator レベルでwrapする]]ことを推奨します。少なくとも現時点では。 ## ベストプラクティスを参考に[[Locator]]の取得戦略を立てる公式ドキュメントのSelectorページにはベストプラクティスの記述があります。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Selectors | Playwright</p> </div> <div class="link-card-description"> Selectors are strings that are used to create Locator]s. Locators are used to perform actions on the... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/selectors#best-practices"></a> </div> 記述方法は上記を参照するとして、推奨される指定戦略は以下になります。 - 人間が文字として認識するものから判断 - テキスト - placeholder - ラベル - ロールとテキストの組み合わせ - [[data-test-id]]から判断 - 『人間が文字として認識するもの』がよく変更される or 特定が困難なものなるべく、人間がブラウザを操作して判断する指標とあわせる形になります。テキストなどの文字として分かりやすいものは言わずもがな、[[data-test-id]]も画面仕様書に記載されたパーツ名と考えれば腑に落ちるでしょう。それらの指標を基に候補が2つ以上存在する場合があるかもしれません。そのときは(デフォルト設定なら)エラーになりますので、そのときに考えればいいでしょう。 ### 候補が2つ以上存在するときの対処法『人間が文字として認識するものから判断』しても候補が2つ以上存在する場合、まずは[[data-test-id]]から判断できるかを考えましょう。ただ、[[UIフレームワーク]]などを使っている場合は特に、[[data-test-id]]が使えないこともあります。[[data-test-id]]をつけても[[トランスパイル]]された[[DOM]]で機能しなくなってしまうケースなどです。そのようなときはレイアウトに基づいたセレクターを使いましょう。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Selectors | Playwright</p> </div> <div class="link-card-description"> Selectors are strings that are used to create Locator]s. Locators are used to perform actions on the... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/selectors#selecting-elements-based-on-layout"></a> </div> 特定要素を起点にして、それよりも上 or 下 or 左 or 右に位置する要素が対象となるため、画面上に複数候補が存在しても、1つに絞れることが多いです。それでも特定が厳しい場合は、`.first()`を使って最も近い要素を取得してもいいでしょう。初めの方に紹介した以下の画像でも、カウンター値を特定するため`:right-of`を使っています。 ![[Pasted image 20221030155444.png]] ## ブラウザの操作から[[Locator]]や操作のテストコードを自動生成するさて。今更ですが、[[Playwright]]にはブラウザ操作からテストコードの一部を作成する機能があります。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Test Generator | Playwright</p> </div> <div class="link-card-description"> Playwright comes with the ability to generate tests out of the box and is a great way to quickly get... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/codegen-intro"></a> </div> `npm run dev`で`localhost:5173`にアプリケーションが起動している状態で以下のコマンドを実行してみましょう。 ```console npx playwright codegen localhost:5173 ``` 操作に対して、ベストプラクティスに極力従うようなコードが生成されます。 ![[2022-10-30-22-56-05.mp4]] とはいえ、これだけで完成とはいきません。[[Locator]]によっては複雑なコードが生成されてしまい、それをそのまま利用するのはアンチパターンです。この機能をこのタイミングで紹介したのは、直前のセクションで[[#ベストプラクティスを参考に Locator の取得戦略を立てる]]方法を紹介済だからです。自動生成されたテストコードの良し悪しが判断でき、必要に応じてコードを変更できる能力があれば、この機能もきっと使いこなせると思います。 ## アプリケーションを起動しつつテストする `webServer`の設定を追加することで、アプリケーションを起動し、疎通できることを確認してからテストを実行できます。また、アプリケーションはテスト終了時に終了します。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Advanced: configuration | Playwright</p> </div> <div class="link-card-description"> Configuration object </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/test-advanced#launching-a-development-web-server-during-the-tests"></a> </div> `playwright.config.ts`に以下の設定を追加します。 ```ts webServer: { command: "npm run dev", port: 5173, reuseExistingServer: !process.env.CI, }, ``` `localhost:5173`にアクセスできないことを確認し、その状態からテストを実行しましょう。 ```console npx playwright test ``` 明示的にアプリケーションを起動させていなかったにもかかわらず、テストが成功します。 > [!hint] `reuseExistingServer`について > `true`にすると既に指定したポート番号のサーバーが起動していたとき、それを使ってテストを開始します。`false`にすると同様のケースではエラーになります。(defaultは`false`) > > 上記の設定ではCIのときのみ`false`となっています。これは、開発中だとテスト実行前に`npm run dev`で開発サーバーを立ち上げていることが多々あり、その場合に終了して起動しなおす手間を省くためです。(意味がないので) > > `reuseExistingServer`が`true`の場合、テストが完了しても起動中のアプリケーションが終了することはありません。 ## [[Docker]]コンテナでテストを実行する最後に、[[Docker]]コンテナを使ってテストを実行する方法を紹介します。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Docker | Playwright</p> </div> <div class="link-card-description"> [Dockerfile.focal] can be used to run Playwright scripts in Docker environment. These image includes... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/docker"></a> </div> 使い捨てのコンテナを作成し、中に入ります。 ```console docker run -it --rm --ipc=host mcr.microsoft.com/playwright:v1.27.0-focal /bin/bash ``` READMEすらテンプレのままですが、コンテナ内でCloneするため[[GitHub]]にリポジトリを作成してpushしました。 <div class="link-card"> <div class="link-card-header"> <img src="https://github.githubassets.com/favicons/favicon.svg" class="link-card-site-icon"/> <span class="link-card-site-name">GitHub</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">GitHub - tadashi-aikawa/playwright-svelte-sample</p> </div> <div class="link-card-description"> Contribute to tadashi-aikawa/playwright-svelte-sample development by creating an account on GitHub. </div> </div> <img src="https://opengraph.githubassets.com/56e9196beaf1ce98eac68d1ab5a391e1b23a3db303c0269015b9cfa21d6db041/tadashi-aikawa/playwright-svelte-sample" class="link-card-image" /> </div> <a href="https://github.com/tadashi-aikawa/playwright-svelte-sample.git"></a> </div> コンテナ内でcloneして実行するだけです。[[Playwright]]で使うブラウザなどの依存関係は公開イメージに含まれているので楽ちんですね。 ```console git clone https://github.com/tadashi-aikawa/playwright-svelte-sample.git cd playwright-svelte-sample npm i npx playwright test ``` 今回触れませんでしたが、各CIサービスにおける書き方は公式ドキュメントで紹介されています。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Continuous Integration | Playwright</p> </div> <div class="link-card-description"> Playwright tests can be executed in CI environments. We have created sample configurations for commo... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/ci"></a> </div> [[Bitbucket Pipelines]]のような[[Docker]]コンテナが母体となっているサービスの場合、基本的に同じようなコマンドを記述することになると思います。[[GitHub Actions]]を使う場合は、[[Playwright]]初期化時の選択肢で`yes`を選んだ方が楽でしょう。 ## おわりに #2022/10/30 時点の[[Playwright]]について、私なりに利用頻度が高そうな機能をキャッチアップの意味合いもこめて、まとめてみました。正直、昨年からの進化に驚きました。以前は様々なツールを組み合わせて、どうにか[[E2Eテスト]]を実現するという感じでしたが、今や[[Playwright]]単体でほぼすべてのことを賄えてしまいます。今回は省略しましたが、Visual comparsionsによる[[ビジュアルリグレッションテスト]]も実用レベルに達していて凄いと思いました。 <div class="link-card"> <div class="link-card-header"> <img src="https://playwright.dev/img/playwright-logo.svg" class="link-card-site-icon"/> <span class="link-card-site-name">playwright.dev</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Visual comparisons | Playwright</p> </div> <div class="link-card-description"> Playwright Test includes the ability to produce and visually compare screenshots using await expect(... </div> </div> <img src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" class="link-card-image" /> </div> <a href="https://playwright.dev/docs/test-snapshots"></a> </div> また、今までは[[IDE]]上でのテストが厳しかったのですが、[[Microsoft]]が[[Playwright Test for VSCode]]を公開してくれたおかげで先行きは明るそうです。最後の障壁としては、私の環境でデバッグのようにブラウザ立ち上げが必要な機能が動かなかったことくらいでしょうか。デバッグ機能は必須ですので、動くようになったら嬉しいなと思っています。[[GitHub]]にIssueは作成済です。 <div class="link-card"> <div class="link-card-header"> <img src="https://github.githubassets.com/favicons/favicon.svg" class="link-card-site-icon"/> <span class="link-card-site-name">GitHub</span> </div> <div class="link-card-body"> <div class="link-card-content"> <div> <p class="link-card-title">Both "Show browser" or "Run in Debug Mode" are not working · Issue #18424 · microsoft/playwright</p> </div> <div class="link-card-description"> Thank you for the great VSCode extension :) However, it doesn't work in both "Show browser&... </div> </div> <img src="https://opengraph.githubassets.com/dcce0b443fe8226a36893a41a9b46db2a9fe5d0f51d848211b2384183973a9fd/microsoft/playwright/issues/18424" class="link-card-image" /> </div> <a href="https://github.com/microsoft/playwright/issues/18424"></a> </div> 個人的には[[#HTMLレポートでテスト結果を確認する]]ことができるので、ターミナルでも困っていることはありません。正直なところ、仕事や[[OSS]]開発で[[Playwright]]が強く必要に迫られたことはほぼありません。それでも[[TypeScript]]を主に扱うWebエンジニア兼QAエンジニアとして、[[Playwright]]のような素晴らしいツールをキャッチアップし、必要な方に普及する活動は続けていきたいと思っています。以下は、2年前の記事の最後に書いた一節です。 > 一方、今はCypressとPlaywrightの2強時代な気がしています。 > それぞれ特徴が異なるため、どちらか一方が残る..という感じではないのかなとも思っています。 > 2つがデファクトスタンダードになれば、GUIテストのメンテナンスコストも落ちるでしょう。 > > そのときが来たら.. 今のUnitテストみたいに.. 誰もがe2eテストを書ける.. > そんな時代の到来を楽しみにしています😁 誰もが[[E2Eテスト]]を書ける時代の到来、今回の記事を書いて、もう既に手の届くところまで来ていることを確信しました。既に普及と浸透のフェーズに入っていると思っています。もし4回目の執筆をする機会があれば、その答え合わせをしましょう。それではまた、1年後のその時まで。