API 測試的劇作家替代方案

如果您是一直使用 Playwright 進行 API 測試的 SDET，您可能非常熟悉處理資料庫相依性、資料管理和無休止的清理需求的挫折感。讓我們面對現實吧 - Playwright 雖然在 UI 測試方面非常出色，但在 API 測試方面卻很麻煩。 但是如果有更好的方法來處理這個問題怎麼辦？

在這篇文章中，我將向您展示如何切換到 Keploy，這是一個開源 API 測試工具，也是 API 測試和模擬 API 的最佳劇作家替代方案。如果您希望簡化測試流程並消除資料庫難題，請堅持下去。這次遷移可能會改變您一直在等待的遊戲規則。

API 測試的 Playwright 概述

Playwright Test 是專門為了滿足端對端測試的需求而創建的。它在自動化瀏覽器互動方面很受歡迎，並將其功能擴展到 API 測試。 Playwright 的 API 測試功能可讓您發出 HTTP 請求、驗證回應，甚至模擬端點。但是，當您依靠 Playwright 在複雜環境中進行 API 測試時，挑戰很快就會增加。

雖然 Playwright 是一個可靠的工具，但以下是我遇到麻煩的一些原因：

• 手動模擬設定：使用 Playwright，您必須為每個 API 互動手動定義模擬回應。這涉及使用 page.route() 設定路由或使用固定裝置攔截網路請求，這可能會變得重複且容易出錯。對於具有許多端點的大型應用程序，這會導致必須管理和維護大量程式碼。

• 覆蓋範圍可能不全面：由於Playwright 主要專注於端到端測試和模擬用戶交互，因此可能只測試UI 程式碼，而底層邏輯（ API調用、後端處理）可能無法完全覆蓋。

• 測試設定開銷：在 Playwright 中設定測試環境，特別是在模擬 API 呼叫時，非常耗時。由於此設定涉及配置路由、回應和數據，因此在運行實際測試之前需要額外的時間和精力。

• 測試運行緩慢：在 Playwright 中手動模擬 API 回應通常涉及為不同端點和回應設定大量模擬。這會增加執行時間，因為每個測試都必須經過多個模擬交互，並且處理大量模擬會減慢進程，特別是對於大型測試套件。

• 與後端邏輯的有限整合：Playwright 的設計重點是瀏覽器交互，而不是 API 或伺服器端測試。因此，如果您正在測試依賴後端 API 或服務的交互，它自然無法提供您的後端程式碼是否被完全覆蓋的可見性。

• 測試隔離問題：劇作家測試通常需要真實或模擬數據，並且設置適當的測試隔離可能很棘手，尤其是在依賴外部數據庫、服務或第三方 API 時。

隨著這些問題的出現​​，我開始尋找一種可以讓 API 測試更簡單、更有效率的解決方案。這就是凱​​普洛伊出現的地方。

為什麼要遷移到凱普洛伊？

Keploy 是一個很棒的 AP​​ 測試工具，它還有助於建立資料模擬/存根。與 Playwright 不同的是，Playwright 通常需要複雜的設定來進行資料庫管理和測試資料創建，而 Keploy 可以自動化其中許多流程。這就是為什麼遷移到 Keploy 對我來說很有意義：

1. 不再需要手動模擬設定

   Keploy 免除了編寫重複的 API 測試程式碼的繁重工作。 Keploy 無需手動定義請求、回應和模擬數據，而是捕獲真實的 API 互動並允許您稍後重播它們。這消除了對大量測試程式碼的需求，並大大減少了測試創建所花費的時間。

2. 無資料庫依賴
   
   Keploy 記錄實際的 API 互動並重播它們以供將來的測試運行，這意味著您不再需要即時資料庫來執行測試。這消除了維護正在運行的資料庫並在每次測試後清理它的開銷。

3. Fa*嚴格測試執行*

   由於 Keploy 不需要設定或拆除資料庫，因此測試執行變得更快。隨著測試已經記錄，準備測試資料或與資料庫互動的需要已經成為過去。

4. 與 CI/CD 輕鬆整合

   Keploy 與 CI/CD 管道無縫集成，提供更快的回饋並提高整體生產力。作為持續整合過程的一部分，您可以輕鬆執行記錄的 API 測試，而無需擔心資料庫狀態或手動測試設定。

5. 全面的測試覆蓋率

   由於 Keploy 記錄了真實世界的 API 交互，因此您可以獲得更準確和完整的測試覆蓋率。透過重播這些記錄的交互，Keploy 可以模擬真實世界的邊緣情況，而手動編寫的測試可能無法完全捕捉這些情況。

從 Playwright 遷移到 Keploy 的步驟

我們將在 NextJS 中運行一個簡單的用戶管理應用程序，並使用 Postgres 作為本指南的資料庫。

步驟 1：評估您目前的 API 測試設置

在深入遷移之前，我首先評估了我在 Playwright 中編寫的現有 API 測試。其中包括：

• 查看我正在測試的所有 API 請求和回應。

• 記錄每個測試所需的設定（例如資料庫狀態和模擬資料）。

• 運行完整的測試套件以檢查任何現有問題並收集測試覆蓋率數據。

我的應用程式的劇作家測試存在於 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 儲存庫中提供了詳細說明。安裝後，我們可以透過在終端機中執行快速檢查來驗證設定：

這確認了 Keploy 已正確安裝並準備就緒。

第 3 步：記錄與 Keploy 的 API 交互

Keploy 的工作原理是記錄測試執行期間發生的實際 API 互動。為了捕捉這些交互，我們需要像往常一樣運行我的 Playwright 測試，但這次使用 Keploy 處於 錄製模式。我的設定方法如下：

1. 使用 Docker Compose 或其他設定啟動應用程式和資料庫。

2. 以記錄模式執行Keploy來捕捉真實的API互動：
   

keploy record -c "npm run dev"

此指令指示 Keploy 擷取 Playwright 測試產生的所有 HTTP 請求和回應。

讓我們運行我們的劇作家測試套件 -

我們可以注意到 keploy 記錄了每個測試案例，這些測試案例是用 playwright 編寫的現有測試套件的一部分。

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 測試案例之一： –

這些測試可以獨立運行，不需要任何外部依賴項，例如即時資料庫。我所要做的就是運行 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 移轉到 Keploy 改變了我的 API 測試流程。以下快速回顧為什麼 Keploy 更適合現代 API 測試：

• 不再有資料庫麻煩：Keploy 消除了對即時資料庫的需求，使您的測試更快、更易於管理。

• 零程式碼測試：不再有重複的測試程式碼 - Keploy 自動化了從資料模擬到測試產生的所有操作。

• 無縫 CI/CD 整合：Keploy 完美融入現有 CI/CD 管道，加快您的回饋週期並提高生產力。

• 真實的測試覆蓋率：Keploy 捕獲真實的 API 交互，確保全面的測試覆蓋率和可靠的結果。

如果您正在努力解決 Playwright API 測試的複雜性，我強烈建議您嘗試 Keploy。這是一種簡單、強大且高效的自動化 API 測試方法，讓您專注於建立高品質的軟體，而不是費力於基礎架構設定和資料管理。

以上是API 測試的劇作家替代方案的詳細內容。更多資訊請關注PHP中文網其他相關文章！