1. テストが「不安定（Flaky）」で信頼できない

テスト結果が不安定だと、自動テストの信頼性が失われ、原因特定に時間がかかります。

【解決策①】

●スマートな待機処理

固定的な待ち時間ではなく、要素が表示されるまで待つなど、状況 に応じた待機を導入します。

例：playwrightには待機処理のために様々なAPIがあります。waitForTimeoutは極力避けて他を利用しましょう。

・固定的な待ち時間を使わない

　極力避けてLocator actions か web assertionsを使いましょう。

・要素が表示されるまで待つ

　optionで表示、非表示等の制御ができます。

・非同期処理の対応を待つ

　actionの前にAPI通信等のurlに対してpromiseを作成します。

　続けてactionと定義したpromiseを呼び出すことでAPI通信等のレスポンスがくるまで待機してくれます。

・URL遷移するまで待つ

・ビューポートサイズの変更等のようにJavaScript関数を使って特定の状態になるまで待つ

・ファイルのダウンロード等のイベント完了まで待つ

【解決策②】

●安定したテスト環境

Dockerなどで環境を統一し、外部依存を減らしてクリーンな状態を 保ちます。

例：Dockerを使いplaywrightの環境をVSCodeのdevcontainerで作成するdevcontainer.jsonの設定をご紹介します。

devcontainer.jsonは次のようになり公式のDocker imageを指定します。

※playwright拡張機能等を追加しています。devcontainerを起動するとnode.jsとnpmがインストールされているので後はnpmでplaywrightを入れればテスト開発、実行環境が作れます。他に入れたいものがあれば併せてnpmで管理しましょう。各ブラウザとブラウザの依存関係についてはdocker imageに入っているのでインストール不要です。

※chromiumではなくブランドブラウザのchromeとEdgeを使いたい場合は追加でインストールが必要です。このようにdevcontainer.jsonを配布するだけでimageをビルドすれば簡単に同じ環境が作れます。

【解決策③】

●ログと分析の強化

失敗時のスクリーンショットや詳細ログを残し、原因特定を迅速化します。

例：様々なオプションを指定してスクリーンショットを撮ることができます。optionで特定の要素をマスクして撮ることもできます。

また、playwrightにはtrace viewerというinspectツールがあります。利用することでエラーの原因特定が容易になります。拡張機能からの使い方はテストエクスプローラーを開いてtrace viewerにチェックを付けテストを起動するだけです。

trace viewerではクリックした位置やその時のネットワークのログ等のデバッグに必要な情報が取得できます。

2. 環境構築と依存関係の管理が複雑

自動テスト環境のセットアップは複雑で、メンバーのオンボーディングやバージョンアップ時の障壁になりがちです。

【解決策①】

●コンテナ技術の活用

Dockerなどでテスト実行環境をカプセル化し、「どこでも動く」状態 にします。

【解決策②】

●依存関係の厳密な管理

rubyの場合はBundler、JavaScriptの場合はnpmなど、適切なツールでライブラリのバージョンを管理します。

例：開発者間でnpmを使った環境を合わせるには、プロジェクトのルートディレクトリにあるpackage.jsonとpackage-lock.jsonという2つのファイルを利用します。これにより、プロジェクトの依存関係を正確に共有・再現できます。

package.jsonとpackage-lock.jsonという2つのファイルを入れた状態でnpm installコマンドを実行すると、このファイルに基づいてすべての依存関係が自動的にインストールされます。

【解決策③】

●詳細なドキュメント

環境構築手順を具体的に記し、常に最新の状態に保ちます。

3. テストデータの準備と管理が大変

テストデータがテストごとに異なると自動テストの運用が困難になります。

【解決策①】

●データの自動生成

javascriptの場合はFaker.jsなどでテストデータを自動生成します。

クリーンアップ：テスト実行後はデータを初期化する仕組みを作ります。

例：Faker.jsはnpmでインストールでき、様々なダミーデータをランダムで作成できます。

インストール方法

npm install @faker-js/faker --save-dev

会員登録等でよく利用される氏名、メールアドレス、パスワードを作成してみます。テストデータとして使いたい場合はDB、csv、json等利用環境に合わせて出力しましょう。

もしplaywrightでランダムなユーザーで会員登録テストをしたい場合は次のようになります。

テスト実行後にテストデータをクリーンアップする場合はplaywright.config.tsにteardownを追加し、その処理の中でデータを初期化します。この実装をすることでテストを開始して全てのテストが終わるとteardownの中の処理が実行され、データが初期化されます。

テスト開始時に実施したい場合はsetupで初期化を実行します。1つのテストファイル内のテスト毎の前又は後で初期化等の特定の処理を実装したい場合はフックを使いましょう。

【解決策②】

●データ駆動型テスト

外部ファイルからデータを読み込むことで、テストケースの追加・変更を容易にします。

例：Faker.jsで出力したデータを外部から読み込ませましょう。

【解決策③】

●モック/スタブの活用

外部依存を減らし、テストデータを制御しやすくします。

例：外部サービスが利用できない又は特定のエラーケースをテストしたい場合はAPIモックを作成しテストしましょう。

page.routeを使うことで代わりにカスタムレスポンスを返します。

APIをpage.route内でawait route.fetch()のようにリクエストしてレスポンスを受け取り修正して返すこともできます。

4. テストの実行速度が遅い

テストケースが増えると実行時間が長くなり、フィードバックが遅れることで開発効率が低下します。

【解決策①】

●並列実行

複数のテストを同時に実行し、全体の時間を短縮します。

例：playwrightの場合はデフォルトでは、並列実行され高速に処理されます。テストは分離し独立した状態で実行するのがベストですが、難しい場合もあるでしょう。もし依存関係のあるテストを並列実行した場合は、テストが失敗してしまいます。どうしても避けることができない場合は、直列実行に切り替えてテストを実施しましょう。

テスト全体を直列実行に変更したい場合は次のように、

playwright.config.tsのfullyParallelをfalseに、workersを1　に変更すると直列になります。

chromium、firefox、webkitの3つのブラウザと3つのテストを実行する場合で、設定を変更すると次のように動作します。テストの依存関係と実行環境の処理能力を考慮して適切な設定を使いましょう。

・fullyParallel: true、workers: 3

各ブラウザとテストが並列実行でそれぞれ別のwokerで実行される。

※ブラウザ3*テスト3で9個のwokerが動く（ただし動作するwokerは設定した3つが上限）

・fullyParallel: false、workers: 3

各ブラウザが別wokerで並列実行し各テストは直列実行される。

※ブラウザごとに1個のwokerが動く

・fullyParallel: false、workers: 1

各ブラウザとテストが1個のworkerで直列実行される。

【解決策②】

●テスト範囲の最適化

実行頻度と範囲を見直し、不要なテストを削除することで無駄をなくします。

５．最後に

上記１～４の課題を理解し、適切な対策を講じることで、自動テストは真価を発揮します。

実践を通して、より堅牢な自動テスト環境を構築しましょう。