イントロ

Playwright のようなエンドツーエンドのテスト フレームワークを使用する場合、ネットワーク リクエストの処理は複雑なタスクになることがよくあります。外部 API に依存するテストは遅くて一貫性がなく、不必要な不安定性が生じる可能性があります。あるテスト実行ではネットワーク呼び出しが成功しても、サーバーが遅いか信頼性が低いために次のテストでは失敗する可能性があり、その結果一貫性のない結果が生じる可能性があります。これに対処するために、開発者はネットワーク リクエストのモック化に頼ることがよくありますが、これによりモックの管理という別の課題が生じます。

複雑なモック戦略を設定せずに、ネットワーク応答のキャッシュと再利用を自動的に処理する方法があれば素晴らしいと思いませんか?既存のアプローチを調査し、紹介したいツールを開発しました。ネットワーク リクエストをファイル システムにキャッシュすることで、これらの問題を正確に解決し、より高速で信頼性の高い Playwright テストを可能にします。

テストにおけるネットワークリクエストの問題

ネットワーク リクエストは、多くの場合、テスト実行で最も遅い部分です。複数のテスト スイートを実行する場合、外部 API のクエリが繰り返されると、テスト時間が大幅に長くなる可能性があります。さらに、実際の API は不安定でタイムアウトが発生する場合があり、テストが脆弱で信頼性が低くなります。

これを軽減する一般的なアプローチは、API 応答を模擬することです。モックは便利ではありますが、手動による介入が必要です。モック応答を慎重に作成し、常に最新の状態に保ち、潜在的なネットワーク シナリオがすべて確実に処理されるようにする必要があります。 API が進化したり、テスト ケースが変更されたりすると、これはメンテナンスの大きな負担になる可能性があります。 Playwright は、ネットワーク トラフィックをキャプチャして再生するための HAR ファイルをサポートしていますが、HAR での作業は面倒な場合があり、その場で応答を変更するための柔軟性に欠けています。

playwright-network-cache を入力してください

playwright-network-cache は、Playwright テストでネットワーク応答をキャッシュするプロセスを合理化し、手動のモックや厳密な HAR ファイルの必要性を排除するように設計されています。このライブラリを使用すると、最初のテスト実行中にネットワーク応答が自動的にファイルシステムに保存され、その後の実行で再利用できるため、テストの実行が大幅に高速化されます。さらに、回答は明確に整理されたフォルダー構造に保存されるため、必要に応じて簡単に検査および変更できます。

問題をどのように解決するか

1. 自動キャッシュ: ライブラリは、テストが初めて実行されるときにネットワーク応答を自動的にキャッシュします。これは、今後の実行でテストが外部 API の応答を待つ必要がなくなることを意味します。代わりにキャッシュされたデータが使用されるため、テストがより高速で信頼性が高くなります。

2. 動的変更: 特定のテスト ケースの応答を調整する必要がありますか? playwright-network-cache を使用すると、キャッシュされた応答を動的に変更できます。ステータス コード、ヘッダー、応答本文のいずれを変更する場合でも、ライブラリには、個別のモックを手動で維持することなく、キャッシュされたデータをオンザフライで調整するオプションが用意されています。

3. 柔軟な構造: キャッシュ システムは、ホスト名、リクエスト メソッド、および URL パスに基づいてファイルを整理し、キャッシュされたデータを簡単に移動して管理できるようにします。より複雑なケースでは、リクエスト クエリ パラメーター、リクエスト本文、またはその他のカスタム フィールドごとにキャッシュ ファイルを分割することもでき、データの保存方法と再利用方法に完全な柔軟性を確保できます。

4. 速度ブースト: キャッシュされた応答を再利用することで、テストはネットワーク呼び出しが完了するのを待つ必要がなくなり、劇的に高速化されます。これは、大規模なテスト スイートを使用する場合、または速度が重要な CI 環境でテストを実行する場合に特に便利です。

5. No More Mock Hell: モックを手動でメンテナンスすることは忘れてください。ライブラリは、キャッシュから再生、さらには応答の変更に至るまで、すべてを処理します。テスト シナリオごとに模擬応答を手動で作成する必要がなくなり、テスト ロジックに集中できるようになります。

6. HAR の複雑さなし: HAR ファイルは、ネットワーク インタラクションの記録と再生に役立ちますが、特に応答を変更する必要がある場合には、すぐに扱いにくくなります。 playwright-network-cache は、個々の応答を単純な JSON ファイルとして管理できるようにすることで、HAR に代わるよりクリーンで柔軟な代替手段を提供します。

例

API から猫のリストを取得するアプリケーションをテストしていると想像してください。キャッシュがなければ、各テストの実行で API へのライブ リクエストが必要となり、テストにレイテンシが追加され、潜在的な障害点が発生します。

playwright-network-cache を使用すると、API 応答を簡単にキャッシュできます:

test('test', async ({ page, cacheRoute }) => {
  await cacheRoute.GET('https://example.com/api/cats');
  // Perform usual test actions...
});

最初の実行では、応答は次のような構造で .network-cache ディレクトリにキャッシュされます:

.network-cache
└── example.com
    └── api-cats
        └── GET
            ├── headers.json
            └── body.json

その後の実行では、キャッシュされた応答が再利用されるため、テストが高速化され、実際の API にアクセスする必要がなくなります。

特定のテストのニーズに合わせてキャッシュされた応答を変更できます:

test('test', async ({ page, cacheRoute }) => {
  await cacheRoute.GET('https://example.com/api/cats', {
    modify: async (route, response) => {
      const json = await response.json();
      json[0].name = 'Kitty-1';
      await route.fulfill({ json });
    }
  });
  // Perform usual test actions...
});

テストで使用できるcacheRoute変数を取得するには、他のPlaywrightフィクスチャと同様にインスタンス化します:

// fixtures.js
import { test as base } from '@playwright/test';
import { CacheRoute } from 'playwright-network-cache';

export const test = base.extend({
  cacheRoute: async ({ page }, use) => {
    const cacheRoute = new CacheRoute(page, { /* cache options */ });
    await use(cacheRoute);
  },
});

ライブラリのドキュメントには他にも多くの例と使用例があります。

単なるキャッシュ以上のもの

playwright-network-cache は単なるキャッシュではありません。次のような高度な機能を提供します:

• 応答の変更: カスタム関数を使用して、キャッシュされた応答内のデータを動的に調整します。
• ステータス コードの処理: エラーを含む、特定の HTTP ステータス コードに基づいて応答をキャッシュします。
• 柔軟なディレクトリ構造: キャッシュ ファイルの保存方法と保存場所をカスタマイズし、ニーズに合わせてキャッシュ戦略を調整できます。
• キャッシュの無効化または更新: 特定のテストのキャッシュを一時的に無効にするか、必要に応じてキャッシュを強制的に更新します。

これらの強力な機能を使用すると、テストでのネットワーク リクエストの管理方法を細かく制御できます。

要約

Playwright テストをより高速かつ信頼性の高いものにしたい場合は、playwright-network-cache を試してみてください。ネットワーク応答をファイルシステムにキャッシュし、動的な変更を可能にすることで、手動のモックの必要性がなくなり、HAR ファイルの柔軟で使いやすい代替手段が提供されます。

読んでいただきありがとうございます❤️