ホームページ >ウェブフロントエンド >jsチュートリアル >API テストのための Playwright の代替手段

API テストのための Playwright の代替手段

DDD
DDDオリジナル
2024-12-29 15:37:10878ブラウズ

Playwright Alternative for API Testing
API テストに Playwright を使用している SDET であれば、データベースの依存関係、データ管理、および際限なくクリーンアップが必要になることに対処する際のイライラをよくご存じかもしれません。正直に言うと、Playwright は UI テストには最適ですが、API テストとなると面倒になる可能性があります。 しかし、これを処理するより良い方法があるとしたらどうでしょうか?

この投稿では、オープンソースの API テスト ツールであり、API テストとモック API に関しては最良の代替手段である Keploy に切り替える方法を説明します。テスト プロセスを合理化し、データベースの問題を解決したい場合は、そのままにしておいてください。この移行は、あなたが待ち望んでいたゲームチェンジャーとなる可能性があります。

API テストのための Playwright の概要

Playwright Test は、エンドツーエンドのテストのニーズに対応するために特別に作成されました。ブラウザーの操作を自動化するために人気があり、その機能が API テストに拡張されています。 Playwright の API テスト機能を使用すると、HTTP リクエストの作成、応答の検証、さらにはモック エンドポイントを作成できます。しかし、複雑な環境での API テストを Playwright に依存している場合、課題はすぐに増大します。

Playwright は強力なツールですが、次のような理由で問題が発生しました。

  • 手動モック設定: Playwright では、API インタラクションごとにモック応答を手動で定義する必要があります。これには、page.route() を使用してルートを設定したり、フィクスチャを使用してネットワーク リクエストをインターセプトしたりすることが含まれますが、これは反復的でエラーが発生しやすくなる可能性があります。多数のエンドポイントを持つ大規模なアプリケーションの場合、これにより、管理および保守が必要なコードが大量に発生します。

  • 対象範囲は包括的ではない可能性があります: Playwright は主にエンドツーエンドのテストとユーザー操作のシミュレーションに重点を置いているため、UI コードのみがテストされ、その基礎となるロジックがテストされる可能性があります ( API 呼び出し、バックエンド処理など)は完全にカバーされていない可能性があります。

  • テストセットアップのオーバーヘッド: Playwright でのテスト環境のセットアップは、特に API 呼び出しをモックする場合に非常に時間がかかります。このセットアップにはルート、応答、データの構成が含まれるため、実際のテストを実行する前にさらに時間と労力がかかります。

  • テスト実行が遅い: Playwright で API 応答を手動でシミュレートするには、さまざまなエンドポイントと応答に対して多数のモックをセットアップすることがよくあります。これにより、すべてのテストが複数のモック化された対話を通過する必要があり、特に大規模なテスト スイートの場合、大量のモックを処理するとプロセスが遅くなる可能性があるため、実行時間が増加します。

  • バックエンド ロジックとの限定的な統合: Playwright は、API やサーバー側のテストではなく、ブラウザーの操作に重点を置くように設計されています。その結果、バックエンド API またはサービスに依存するインタラクションをテストしている場合、バックエンド コードが完全にカバーされているかどうかを確認することは当然できません。

  • テスト分離の問題: Playwright テストでは実際のデータまたは模擬データが必要になることが多く、特に外部データベース、サービス、またはサードパーティ API に依存する場合、適切なテスト分離を設定するのは難しい場合があります。

これらの問題が山積するにつれて、私は API テストをよりシンプルかつ効率的にできるソリューションを探し始めました。そこでケプロイが登場しました

Keploy に移行する理由

Keploy は API テストに最適なツールであり、データ モック/スタブの作成にも役立ちます。データベース管理やテスト データ作成に複雑な設定が必要なことが多い Playwright とは異なり、Keploy はこれらのプロセスの多くを自動化します。私にとって Keploy への移行が理にかなった理由は次のとおりです:

  1. 手動でのモックセットアップは不要

    Keploy は、反復的な API テスト コードを記述するという骨の折れる作業を軽減します。 Keploy は、リクエスト、レスポンス、モックデータを手動で定義する代わりに、実際の API インタラクションをキャプチャし、後でそれらを再生できるようにします。これにより、大規模なテスト コードの必要性がなくなり、テストの作成にかかる時間が大幅に短縮されます。

  2. データベース依存性なし

    Keploy は実際の API インタラクションを記録し、将来のテスト実行のためにそれらを再生します。つまり、テストを実行するためにライブ データベースが必要なくなります。これにより、実行中のデータベースを維持したり、各テスト後にデータベースをクリーンアップしたりするオーバーヘッドが排除されます。

  3. ファ*スターテストの実行*

    Keploy ではデータベースのセットアップや破棄が必要ないため、テストの実行がはるかに高速になります。テストがすでに記録されているため、テスト データを準備したりデータベースを操作したりする必要は過去のものになりました。

  4. CI/CD との簡単な統合

    Keploy は CI/CD パイプラインとシームレスに統合し、より迅速なフィードバックを提供し、全体的な生産性を向上させます。データベースの状態や手動のテスト設定を気にすることなく、継続的統合プロセスの一部として記録された API テストを簡単に実行できます。

  5. 包括的なテスト範囲

    Keploy は実際の API インタラクションを記録するため、より正確で完全なテスト カバレッジを達成できます。これらの記録されたインタラクションを再生することで、Keploy は、手動で作成したテストでは完全には捕捉できない可能性がある現実世界のエッジケースをシミュレートできます。

Playwright から Keploy に移行する手順

このガイドでは、Postgres をデータベースとして NextJS で単純なユーザー管理アプリケーションを実行します。

ステップ 1: 現在の API テスト設定を評価する

移行に入る前に、まず Playwright で作成した既存の API テストを評価しました。これには以下が含まれます:

  • テストしていたすべての API リクエストとレスポンスを確認します。

  • 各テストに必要な設定 (データベースの状態や模擬データなど) を文書化します。

  • 完全なテスト スイートを実行して、既存の問題を確認し、テスト カバレッジ データを収集します。

私のアプリケーションの Playwright テストは、test フォルダーの下の app.spec.ts にあります。

import { test, expect } from '@playwright/test';

const apiUrl = 'http://localhost:3000/api/users';  // Application is running on port 3000

test.describe('User API Tests', () => {

    // Test GET request (Fetch all users)
    test('GET /api/users should return a list of all users', async ({ request }) => {
        const response = await request.get(apiUrl);
        expect(response.status()).toBe(200);  // Ensure status code is 200
        const body = await response.json();
        expect(body.users).toBeInstanceOf(Array);
    });    
});

現在のテスト状況を明確に理解したら、次に進むべき時が来ました。

ステップ 2: Keploy のインストールと環境のセットアップ

次のステップは、Keploy をテスト環境にインストールすることでした。 Keploy のインストール プロセスはシンプルで簡単で、詳細な手順は Keploy GitHub リポジトリで入手できます。インストール後、ターミナルでクイックチェックを実行してセットアップを確認できます:

Playwright Alternative for API Testing

これにより、Keploy が正しくインストールされ、使用できる状態になったことが確認されました。

ステップ 3: Keploy との API 対話を記録する

Keploy は、テスト実行中に発生する実際の API インタラクションを記録することによって機能します。これらのインタラクションをキャプチャするには、いつものように Playwright テストを実行する必要がありますが、今回は Keploy 録画モード で実行します。設定方法は次のとおりです:

  1. Docker Compose または別のセットアップを使用してアプリケーションとデータベースを起動します。

  2. Keploy を レコード モード で実行して、実際の API インタラクションをキャプチャします:

keploy record -c "npm run dev"

このコマンドは、Playwright テストによって生成されたすべての HTTP リクエストとレスポンスをキャプチャするように Keploy に指示しました。

Playwright Alternative for API Testing

Playwright テストスイートを実行しましょう -

Playwright Alternative for API Testing

Playwright で書かれた既存のテストスイートの一部である各テスト ケースを keploy が記録していることがわかります。

Playwright Alternative for API Testing

Keploy によって生成された各テスト ケースは、Playwrigth テスト ケースです: –

test('POST /api/users should create a new user', async ({ request }) => {
        const newUser = {
            name: 'John Do',
            email: 'johndoee@xyz.com'
        };

        const response = await request.post(apiUrl, {
            data: newUser
        });

        expect(response.status()).toBe(200);  // Ensure status code is 200
        const body = await response.json();
        expect(body.users[0]).toHaveProperty('id');  // Check if the first user in the array has an ID
        expect(body.users[0].name).toBe(newUser.name);
        expect(body.users[0].email).toBe(newUser.email);
    });


    // Test PUT request (Update an existing user)
    test('PUT /api/users should update an existing user', async ({ request }) => {
        // First, create a new user to update
        const newUser = {
            name: 'Jane Doe',
            email: 'janedoe@example.com'
        };

        let response = await request.post(apiUrl, {
            data: newUser
        });

        // Check if the POST request was successful
        expect(response.status()).toBe(200); // Ensure status code is 200
        const createdUser = await response.json();
        expect(createdUser.users).toHaveLength(1);
        const userId = createdUser.users[0].id;

        // Prepare the updated user data
        const updatedUser = {
            id: userId,
            name: 'John Deo',
            email: 'updated@example.com'
        };

        // Make the PUT request to update the user
        response = await request.put(apiUrl, {
            data: updatedUser
        });

        // Check if the PUT request was successful
        expect(response.status()).toBe(200);
        const body = await response.json();

        // Check if the updated fields match the new values
        expect(body.users[0].name).toBe(updatedUser.name);
        expect(body.users[0].email).toBe(updatedUser.email);
    });    

    // Test DELETE request (Delete a user)
    test('DELETE /api/users should delete a user', async ({ request }) => {
        // First, create a user to delete
        const newUser = {
            name: 'Mark Doe',
            email: 'markdoe@example.com'
        };

        let response = await request.post(apiUrl, {
            data: newUser
        });

        // Check if the response body is empty or invalid
        if (!response.ok()) {
            console.error('Failed to create user', await response.text());
            expect(response.ok()).toBe(true);  // Fail the test if the response is not OK
        }

        const createdUser = await response.json();
        if (!createdUser || !createdUser.users || createdUser.users.length === 0) {
            console.error('Invalid response format:', createdUser);
            throw new Error('Created user response format is invalid');
        }

        const userId = createdUser.users[0].id;  // Accessing the ID of the newly created user

        // Delete the created user
        response = await request.delete(apiUrl, {
            data: { id: userId }  // Sending the ID of the user to be deleted
        });

        // Check if the delete response is valid
        expect(response.status()).toBe(200);  // Ensure status code is 200
        const body = await response.json();
        expect(body.users[0].id).toBe(userId);  // Ensure the correct user is deleted
    });

ステップ 4: 記録されたインタラクションをテストとして再生する

インタラクションが記録されると、Keploy は対応するテスト ケースを自動的に生成しました。以下は、そのような keploy テスト ケースの 1 つです: –

Playwright Alternative for API Testing

これらのテストは、ライブ データベースのような外部依存関係を必要とせずに、独立して実行できます。私がしなければならなかったのは、Keploy のテスト スイートを実行することだけでした:

import { test, expect } from '@playwright/test';

const apiUrl = 'http://localhost:3000/api/users';  // Application is running on port 3000

test.describe('User API Tests', () => {

    // Test GET request (Fetch all users)
    test('GET /api/users should return a list of all users', async ({ request }) => {
        const response = await request.get(apiUrl);
        expect(response.status()).toBe(200);  // Ensure status code is 200
        const body = await response.json();
        expect(body.users).toBeInstanceOf(Array);
    });    
});

このコマンドは、記録されたインタラクションの再生をトリガーし、実際のデータベースを必要とせずに API をテストしました。

Playwright Alternative for API Testing

結論

Playwright から Keploy への移行は、私の API テスト プロセスにとって大きな変化でした。 Keploy が最新の API テストに非常に適している理由を簡単に要約します。

  • データベースの煩わしさはもうありません: Keploy を使用すると、ライブ データベースが不要になり、テストが高速化され、管理が容易になります。

  • ゼロコード テスト: 繰り返しのテスト コードは不要です。Keploy は、データ モックからテスト生成まですべてを自動化します。

  • シームレスな CI/CD 統合: Keploy は既存の CI/CD パイプラインに完全に適合し、フィードバック サイクルを高速化し、生産性を向上させます。

  • 現実的なテスト カバレッジ: Keploy は実際の API インタラクションをキャプチャし、包括的なテスト カバレッジと信頼できる結果を保証します。

Playwright の API テストの複雑さに苦労している場合は、Keploy を試してみることを強くお勧めします。これは API テストを自動化する簡単、強力、効率的な方法であり、インフラストラクチャのセットアップやデータ管理に苦労することなく、高品質のソフトウェアの構築に集中できます。

以上がAPI テストのための Playwright の代替手段の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。