今回EC2内でPlaywrightの実行環境を構築する機会がありましたので
記録として残しておきます。今回はスペックが高くないマシンで試行錯誤しつつ無事に安定的な環境を構築できたので、AWS使っている人は見てもらえると良いかなと思います。
使用する容量:1GB程度
前提となる環境は以下となります
・AmazonLinux2023 (t3micro, 20G)
・Laravelプロジェクト
・npmは導入済み
1. Playwrightの初期化
プロジェクトのルートディレクトリで以下のコマンドを実行します。
npm init playwright@latest
追記
axiosの問題があったので、latestではなくnpm公式よりバージョンの安全性をチェックしてからインストールしてください。
https://npmjs.com
2. 初期設定の質問への回答
インストール時に表示される質問には以下のように回答します。
-
TypeScript or JavaScript?:
TypeScript/JavaScript- ※TypeScriptにしてもテスト実行時にPlaywright側でJSにトランスパイルされるので、好きな方を選択
-
Where to put your end-to-end tests?:
e2e(既存のtests/と分けるため) -
Add a GitHub Actions workflow?:
false(bitbucketなので) -
Install Playwright browsers?:
true
※以下、TypeScript指定とする
3. システムライブラリのインストール
ブラウザ依存関係のシステムライブラリをインストールします。
npx playwright install-deps
- ※AmazonLinux2023はCUIなので、ブラウザに関するライブラリは導入し、それ以外のOSのGUI系ライブラリは導入しない。(動かないので)
4. ブラウザ実行用ライブラリのインストール
ブラウザを実行するためのライブラリをインストールします。
sudo dnf install -y \
alsa-lib at-spi2-atk at-spi2-core atk cairo cups-libs \
dbus-libs expat fontconfig freetype gdk-pixbuf2 glib2 \
gtk3 libX11 libXcomposite libXcursor libXdamage libXext \
libXfixes libXi libXrandr libXrender libXtst libdrm \
libgbm libxkbcommon pango mesa-libgbm
※ アンインストールしたい時は以下
# Playwrightが管理しているブラウザバイナリの削除
npx playwright uninstall --all
# プロジェクトからPlaywright(パッケージ)を削除
npm uninstall @playwright/test
# dnfで入れたものを削除
sudo dnf remove -y \
alsa-lib at-spi2-atk at-spi2-core atk cairo cups-libs \
dbus-libs expat fontconfig freetype gdk-pixbuf2 glib2 \
gtk3 libX11 libXcomposite libXcursor libXdamage libXext \
libXfixes libXi libXrandr libXrender libXtst libdrm \
libgbm libxkbcommon pango mesa-libgbm
# 未使用の依存パッケージを削除
sudo dnf autoremove -y
# パッケージマネージャのキャッシュを削除
sudo dnf clean all
5. ブラウザバイナリのインストール
ブラウザのバイナリをインストール(OS側のライブラリ(deps)を除く)します。
npx playwright install chromium
6. 設定ファイルの編集(playwright.config.ts)
インストール後に playwright.config.ts が作成されるので、以下の変更分を反映する。.envはtestingを指定。(なければ用意)
export default defineConfig({
testDir: './tests',
use: {
baseURL: 'http://127.0.0.1:8000',
trace: 'on-first-retry',
},
webServer: {
command: 'php artisan serve --env=testing --host=127.0.0.1 --port=8000',
url: 'http://127.0.0.1:8000',
reuseExistingServer: !process.env.CI,
},
});
7. ディレクトリ構成の作成
Laravel10のtestのディレクトリ構成を以下のように作っておくと、視認性が良くなります。このあたりはプロジェクトの構成もあると思うので良さそうな階層分けを検討してみてください。
tests
└── e2e
└── pages
├── default
│ ├── common
│ │ └── top.spec.ts(例:トップページ)
│ └── user
└── mobile
├── common
│ └── top.spec.ts(例:トップページ)
└── user
…
8. 日本語フォントの追加(スクリーンショットを撮った際に文字化けするのを防ぎます)
sudo dnf install google-noto-sans-jp-fonts -y
9. テストコードの作成
実際にテストを書く(tests/e2e/pages/default/common/top.spec.ts)
import { test, expect } from '@playwright/test';
test('トップページが表示される', async ({ page }) => {
await page.goto('http://127.0.0.1:8000');
await expect(page).toHaveTitle('タイトル');
});
10. テストの実行と確認
実際にテストケースを指定して実行し、結果を確認します。
npx playwright test tests/e2e/pages/default/common/top.spec.ts --project=chromium
11. その他便利コマンド
-
デバッグモードで実行
DEBUG=pw:browser npx playwright test -
chromeだけで実行
npx playwright test --project=chromium -
対象を指定(ファイル)
npx playwright test tests/e2e/pages/mobile/forms/account/login.spec.ts -
対象を指定(ディレクトリ)
npx playwright test tests/e2e/ --project=chromium -
特定のテスト名で絞り込み
npx playwright test -g "ログイン" --project=chromium -
ファイルの一部を絞り込んで実行
npx playwright test auth --project=chromium -
特定の行だけを指定して実行
npx playwright test tests/e2e/example.spec.ts:15 --project=chromium -
スマートフォン表示で実行
npx playwright test --project=mobile-chrome -
E2Eテストを実行するとキャッシュが溜まるので、実行した後プロセスとともに解放
pkill -f chromium || true sudo sync; echo 3 | sudo tee /proc/sys/vm/drop_caches > /dev/null -
パスの指定は、以下で返ったきたものを設定(確認用に使う)
find . -name "top.spec.ts" -
ディレクトリ構造を可視化
ls -R tests -
スクリーンショットが文字化けする時は以下を追加
sudo dnf install -y google-noto-sans-japanese-fonts -
テスト中の様子をスクリーンショットや動画で保存
export default defineConfig({ use: { screenshot: 'on', // テスト終了時に撮影 video: 'retain-on-failure', // 失敗した時だけ動画を残す trace: 'on', // 詳細な操作ログ(トレース)を残す }, }); -
Trace Viewerを使う
- 以下のサイトにドラッグ&ドロップで解析
- https://playwright.dev
※1
EC2内でローカルサーバーを立てて、1プロセスで実行するので低速ですが
これで比較的厳しめな制約下でも動きます。ただ、vscode経由で動かすとフリーズしやすいので、SSHで接続したターミナルからPlaywrightの実行をコマンドを叩く感じになります。
※2
※1の補足として、テストの機能網羅が複数ステップある場合は
3つ〜4つを1パターンとして分割しながら作成することを推奨します。
1パターンの中にすべてのテストケースが入っている構成だと、キャッシュが溜まりやすくなってしまいテスト実行時の制御がおかしくなることがありました。
分割することで、ユーザー情報のインスタンスがテストケースごとにリフレッシュされた状態で実行されるので、比較的スムーズに処理が進むようになります。
※3
セキュリティの観点から推奨はされないですが、ローカルで使用しているMacBookなどのマシンで実行する場合は
並列実行もできてかなり爆速になります(数十分かかるものが数分で完了するレベル)。
今回のようにクラウドのサーバーで実行する場合
特にAmazonLinux2023ではSafariのブラウザエンジンをインストールしようとするとコケてしまうことがあり、かつ低速で全部のブラウザで動作確認できないという欠点もありました。
一方ローカルマシンのMacBookであれば、例えばSafariは勿論ネイティブ環境なのでこのような問題を回避可能になります。ということで、実行環境だけはローカルでやるというように、
運用上の工夫を検討してみることもアリかと思います。