3週間の自動テストが半日に！ Playwrightの使い方の基本

2025年09月05日 15時00分更新

文● 齋藤唯維／FIXER

　本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「Playwrightで自動テストを実装したときの話を書くぞ～～～」を再編集したものです。

自動テストを作りました!!!!

なんでそんなことをしたのかという話

　とあるプロジェクトのリリース前には、割と莫大な量のテストを行う必要がありました。

　しかも週一ペースで、手動で。なんとな～く想像はつくと思いますが、超超超時間がかかった訳です。
　
　チームメンバーに担当か所の割り振りして、画面のスクショとって、エビデンス作って、エビデンスの再鑑して…

『スクリーンショットの画面が足りないからテスト最初からやり直し!!!!!』
『エビデンス、この項目足りてなくない？ちゃんと見た？』
『テストの進みが遅くない？リリース間に合う？』
『エビデンス格納のExcelが超重い😡😡😡😡😡』
『期限までに間に合わない😭😭😭』

　みんな人間なので、集中力もいつかは切れます。

　私たちの悩みはいつもひとつ……

『『『リリース前の手動チェックに時間がかかりすぎるよ～～～😭😭😭』』』

　この悩みを解決してくれるのが、Playwrightってわけ。

　Playwrightのおかげで、10人規模で約3週間も時間がかかっていたテストが、4人で半日で終わるようになっちゃったんですね～～～!!!

　マジで素晴らしい。Playwrightでの開発に関わってくださった人達みんな最強!!! 褒めてほしい。

☺️＜えらいね～

↑うれしい

Playwrightってなにもの？

　一言でいうと、「ユーザーが実際にサイトを操作するのと同じ流れ（エンドツーエンドテスト）を、自動で実行してくれる超強力なツール」です。

　Playwrightの公式Documentのリンク貼っておきます。

　詳しくはそちらを参考にしてください。
https://playwright.dev/docs/intro

Playwrightのここがすごい

1. あらゆるブラウザに対応🌐

　Playwrightは、Google ChromeやMicrosoft Edgeの元になっているChromium、Safariの元になっているWebKit、そしてFirefoxという、世界の主要なブラウザエンジンをすべてサポートしています。これにより、「このブラウザだけで動かない」といった問題を確実に捉えることができます。

2. どんな環境でもテスト可能 💻

　あなたのPCがWindowsでも、Macでも、Linuxでも問題なく動作します。さらに、テスト実行中にブラウザ画面を表示させて動きを確認したり（ヘッドフル）、裏側で高速に実行したり（ヘッドレス）することも可能です。開発中のデバッグから、CI/CDツールと連携した自動化まで、あらゆるシーンで活躍します。

私たちが実装した自動テストの詳細

・ブラウザ
　Chromium

・実装環境
　Windows

・自動テストの機能
　画面操作
　スクリーンショットを撮影
　文字検証

Playwrightを使えるようにする手順

　ここからは、Playwrightを使うためのアレコレを簡単に説明していきます。
　
　コマンドに関してですが、コードブロックにするとますます読みにくくなるので太字にしてます。許して。

環境構築・設定のやり方（Playwright実装用のリポジトリがある場合）
1. 管理者用でターミナルを開く
2. npm install -g yarnを行い、yarnを確認する
　→既に入っている場合、file already existsと表示される
3. git clone（gitのhttpsをコピー）する
4. クローンしたリポジトリをVScodeで開く
5. ターミナル（GitBash）でyarn installを実行
6. yarn playwright installを実行
7. yarn playwright install-depsを実行

8. 拡張機能 Playwright Test for VSCodeをインストール

9. 拡張機能のインストール後、VSCodeの再起動を行う
10. VSCodeのサイドバーにフラスコマークの「テスト」が追加されるため、それをクリック

11. PLAYWRIGHTをクリックし、以下の項目にチェックを入れる
・PROJECTS の chromium
・SETTINGS の Show browser

環境変数の設定手順

1. .envという名前のファイルを作成する
2. .envファイルに環境変数を設定する
　テストケースのpath設定はここで行う

フォルダ構成

・tests/ Playwright テストの本体
　・テストファイル名.spec.ts playwright によるテストの記述
　　all.spec.tsで全テストケースが網羅されている
　　テストケースごとに実行できる
・constants/ テスト間で使いまわす定数の置き場
・interfaces/ テストで利用するインターフェース
・utils/ テスト間でサブルーチン的に使えるテストフローなどの置き場
・.env/ (Git リポジトリ上にはない) playwright のテスト時の環境変数設定ファイル
・.env.sample/ .env ファイルに書く内容のテンプレ
・playwright.config.ts/ Playwright の設定ファイル

テストケース追加方法

1. Excelで空白のブックを開く
2. A1セルを左端として、１行目にヘッダー項目を記入する
3. A2以下の行は、作成したいテストケースを入力する
　例：アイスを注文するテストケース

4. テストケースを記入し終わったら、拡張子を.csvに変更して保存する
5. 保存したテストファイルを環境変数やコード上に設定してテストデータを読み込む

⚠️注意⚠️

　上記のテストケースはブログ用に限りなくわかりやすくするための例であり、実際のテストケースはもっとヘッダーの量が多くなります。

CSVをオブジェクトに変換する

　今回のテストではCSVを読み込んだ後、interfaceで型付けを行いました。

export interface OrderInfo{
     iceInfo: IceInfo[],
     containerType: string,
     notes: string
}

export interface IceInfo{
     iceName: string,
     size: string,
     quantity: int,
}

　こうすることで

・型安全性の向上
・コードの可読性の向上
・リファクタリングの容易さ

　などのメリットがあります。

　CSVは構造が単純なので、IceInfoなどリストの長さを自由には変えることはできません（そのためにはメニュー１、メニュー２、メニュー３と列を増やす必要がある）。ですが、今回はテストケースを量産したかったので、リストの長さは最大2を想定してCSVを作成しました。

テスト実施方法

1. サイドバーの「フラスコ」マークの「テスト」をクリック
2. 「＞テストエクスプローラー」をクリック

3. 「＞tests」が表示されるので、それをクリック

4. 「＞all.spec.ts」をクリックすると、.envで設定したテストケースが表示される

5. 「テストの実行」をクリックすると、青いChromeのようなものが立ち上がりテストが実行される

テスト実施における注意点⚠️

　テストを行うたびにreportが発行される仕組みになっており、エビデンスとして格納する必要があります。

　しかし、テストを回し終えた際に、続けて別のテストを行ってしまうとreportが上書きされてしまい、前回実行したテスト結果がなくなってしまいます😖

　reportの上書きを防ぐため、テストを行う際はテストエクスプローラーのリロードを行ってからテストを実行すると新規reportとして保存されるので、リロードをしないままテストを実行してしまわないように気を付けましょう！

テストを実施するときのポイント

テストが通らない🤔

　自動テストの操作が早くてPCの処理が追いつかなかったり、ネットワークの問題でモーダルが表示されなかったり、『いつもテスト成功してくれるのに、どうしてそこで失敗するんだ…？』となることがあります。私たちは割と高頻度でありました……。

　この問題を明確に解決する方法は無いですが、自動テストを行っている画面をバックグラウンドにせず、表示させておくだけでテストが完了まで通りやすくなるので、困った際はやってみてください。（けど正直気休めレベル！これやってみたらうまくいく時が多くなった感覚はある！）

特定のテストケースだけ実行したい🤔

　Ctrlを押しながら実行したいテストケースのみクリックすると、クリックしたテストのみ実行することができます。

　全部のテストケースを実行した後に、失敗したテストケースだけやり直すときなどに便利！

出力されるエビデンス

playwright-report

　テストを実行する度にreportが出力される。

・data
　まとめて行ったテストのスクリーンショットやPDFが格納されている
・index.html
　テストが成功したか、失敗した場合どの部分で落ちたのかが記録されている

その他自動テスト内で出力されるようにしたもの

　今回の場合だと、私たちはエビデンスの信憑性を高めるためにスクリーンショットを撮影し、出力する機能を付け足しています。この辺は各プロジェクトによって色々違うと思うので、臨機応変に対応してください。

Playwrightを触ってわかったこと

Tailwind CSSとPlaywrightの相性と、変更に強いテストの書き方✒️

　Tailwind CSSは、mr-1（margin-right: 4px）のように、見た目のスタイルをそのままクラス名としてHTMLに記述するライブラリです。この仕組みは、UIを少し変更しただけでクラス名が変わってしまうため、クラス名に依存したPlaywrightのテストは脆くなりがちです。しかし、この課題はテストの書き方次第で克服できます。変更に強いテストを書くには、テストの目的が操作の「実行」なのか「検証」なのかを意識し、アプローチを変えることが重要です。

１．操作の「実行」は、変更に強い😄

　ボタンをクリックする、フォームに入力するといった「実行」が目的のテストは、UIの変更に強く作ることができます。Playwrightでは、mr-1のような変わりやすいスタイリング用のクラスではなく、getByRole()などユーザーの操作に紐づく方法で要素を特定することが推奨されます。このアプローチを取れば、UIのデザインが変更されてもテストは安定して動作します。

２．クラス名に依存した「検証」は、変更に弱い😞

　一方で、クラス名を頼りに要素を特定し、その内容を検証するテストは、UIの変更に非常に弱いです。例えば、「ボタンの余白を広げる」という軽微なUI修正でクラス名がmr-1からmr-2に変わったとします。このクラス名を頼りに文字を検証していたテストは、機能的には何も変わっていないにも関わらず失敗してしまいます。これは、デザインの変更に直接影響される、脆いテストと言えるでしょう。

locatorとgetByTextは要素によって使い分ける

　以下の表は、locatorとgetByTextを比較したものです。私たちはlocatorを多用して実装を行いましたが、要素によって適切なメソッドを使用することが大切です。