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​​I 测试工具，它还有助于创建数据模拟/存根。与 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中文网其他相关文章！