MIT License

项目介绍

playwrightsolutions/playwright-api-test-demo 是一个托管在 GitHub 上的开源项目,主要使用 TypeScript 编写,采用 MIT License 许可证,目前获得 111 个 Star、38 次 Fork。

仓库全名
playwrightsolutions/playwright-api-test-demo
开源许可证
MIT License
Star 数
111
Fork 数
38

README 摘要

playwright-api-test-demo This repository will serve as a place where I add API test Automation checks for articles written at Useful Swagger Links Auth Swagger UI Booking Swagger UI Room Swagger UI Branding Swagger UI Report Swagger UI Message Swagger UI Contributing to playwright-api-test-demo Husky, ESLint, and Prettier We use a mix of Husky, ESLint and Prettier within our repository to help enforce consistent…

完整内容见 GitHub 原始 README 或本页 。

常见问题

playwright-api-test-demo 用什么语言开发?

主要使用 TypeScript 编写,采用 MIT License 许可证,目前有 111 个 Star。

playwright-api-test-demo 可以免费商用吗?

仓库采用 MIT License 许可证,可免费使用与修改,商业使用请遵守许可证条款(例如保留版权声明与许可声明)。

如何获取 playwright-api-test-demo 的源码?

可以直接克隆仓库:git clone https://github.com/playwrightsolutions/playwright-api-test-demo.git,默认分支为 main;安装与运行步骤见仓库 README。

playwright-api-test-demo 最近还在维护吗?

仓库最近一次更新为 2025年3月1日,当前没有未关闭的 Issue;Star 数为 111,可作为社区活跃度的参考。

关于

GitHub 原始描述(英文)

This repository will serve as a place where I add API test Automation checks for articles written at https://playwrightsolutions.com

描述取自 GitHub 官方 API,保持仓库作者书写的原文。

简要分析

热度分
196
价值分
78
活跃状态
活跃

语言占比

JavaScript
Shell
TypeScript

README

playwright-api-test-demo

This repository will serve as a place where I add API test Automation checks for articles written at https://playwrightsolutions.com

Contributing to playwright-api-test-demo

Husky, ESLint, and Prettier

We use a mix of Husky, ESLint and Prettier within our repository to help enforce consistent coding practices. Husky is a tool that will install a pre-commit hook to run the linter any time before you attempt to make a commit. This replaces the old pre-commit hook that was used before. to install the pre-commit hook you will need to run

npm run prepare
npx husky install

You shouldn’t have to run this command but for reference, the command used to generate the pre-commit file was

npx husky add .husky/pre-commit "npm run lint && npm run prettier"

You are still able to bypass the commit hook by passing in --no-verify to your git commit message if needed. ESLint is a popular javascript/typescript linting tool. The configuration for ESLint can be found in .eslintrc.cjs file. Prettier, helps with styling (spaces, tabs, quotes, etc), config found in .prettierrc.

Json Schema

We generate json schemas with a POST, PUT, PATCH and GET test but not with a delete. To generate a json schema. An example of a test that generates a schema is below. It’s best to follow the similar naming conventions

// Creates a snapshot of the schema and save to .api/booking/POST_booking_schema.json
await validateJsonSchema("POST_booking", "booking", body, true);

// Asserts that the body matches the snapshot found at .api/booking/POST_booking_schema.json
await validateJsonSchema("POST_booking", "booking", body);

Example of how this is used in a test:

import { test, expect } from "@playwright/test";
import { validateJsonSchema } from "@helpers/validateJsonSchema";

test.describe("booking/ POST requests", async () => {
  test("POST new booking with full body", async ({ request }) => {
    const response = await request.post("booking/", {
      data: requestBody,
    });

    expect(response.status()).toBe(201);
    const body = await response.json();
    await validateJsonSchema("POST_booking", "booking", body);
  });
});
  • To make sure that response body schema is what we should expect based on our documentation we use validateAgainstSchema() function which takes the following parameters:

    • Definition: Validates an object against a specified schema object

    • object - The object to check schemaObject against.

    • schemaObject - The schema object name as documented in *_spec3.json.

    • docs - The type of docs (e.g. public, internal or admin).

    • notReturnedButInSchema - Any defined properties in schema but not returned by Falcon.

    • extraParamsReturned - Any undefined properties returned by Falcon; create a bug if there are any.

      await validateAgainstSchema(body.user, "User", "public", [
      "verification_code"]);
      

    This function will validate the object from response (1st param) against the object (2nd param) from the documentation (3rd param), ignoring the fact that docs have more parameters defined (4th params). It will count keys in the returned and docs objects and validate that they have the same names. IF there is a mismatch -> there is going to be a failure on .toEqual since we validating keys from response and docs objects placing them in sorted arrays

    // compare object keys (need to be sorted since order differs)
    expect(docsObjectKeys.sort()).toEqual(responseObjectKeys.sort());
    

    The only thing which is not achieved with this approach is the fact there is no way for us to know if a new parameter is added. We have to track on our side how many keys each object has.

./lib/helpers/schemaData${docs} which store objects and their parameter counts. When validateAgainstSchema() function finishes comparison of response and doc objects we then check docs object keys count vs what we store for that object. If there is a mismatch - a warning will be triggered at the end of run. Notice: test is not failing and just adds a warning which will give you directions what test needs to be updated (since there are possibly new params) and that you need to update our tracking files.

To update tracking files you need to run any test with GENERATE_SCHEMA_TRACKING_DATA=true. It will overwrite existing 3 files BUT it’s you who have to commit and push them to our repo.

评论

暂无评论