@macpaw/qa-http-request-builder

qa-http-request-builder

Description

This package is built on around of various libraries for HTTP requests:

• Got. Support version 12.6.1
• Playwright API

[!WARNING] This package is native ESM and no longer provides a CommonJS export. If your project uses CommonJS, you'll have to convert to ESM or use the dynamic import() function.

How to use the library in the project

• To get started with the HTTP builder, you should add the package to your project:

npm i -D @macpaw/qa-http-request-builder

• For API requests, override the httpRequest() method in your BaseService and choice library:

  • Got:

  export interface HttpRequestParams {
      token?: string;
      cookies?: string[];
      appURL?: string;
  }
  
  // Got HTTP lib
  class BaseService {
    protected params?: HttpRequestParams;
  
    constructor(params?: HttpRequestParams) {
      this.params = params;
    }
  
    httpRequest() {
      const service = OuterApiService.useGot(this.params);
  
      return service.httpRequest();
    }
  }
  
  

  • Playwright

[!Important] It is also recommended to specify the baseURL in the use: {} section of your config, so that tests can use relative urls and you don't have to specify the full URL over and over again.

  // Playwright HTTP lib
  export interface HttpRequestParams {
      token?: string;
      cookies?: Cookies[];
  }

  class BaseService {
    protected params?: HttpRequestParams;

    constructor(params?: HttpRequestParams) {
      this.params = params;
    }

    httpRequest() {
      const service = OuterApiService.usePLaywright(this.params);

      return service.httpRequest();
    }
  }

Initialize project locally

1. Clone repository

git clone [e-mail]:MacPaw/qa-http-request-builder.git

2. (Optional) Running example tests

• Init local env variables

  # copy configuration
  cp .env.example .env
  

• To use the API gorest for testing need to add AUTH_KEY in .env. Token can find in the 1password. If the token expired you can generate a new one after registration in gorest

• The testing example you can find in the project directory /example.

• Use the script to run tests:

  npm run test:example
  

Library Release Process

Our library release process is designed to ensure quality, consistency, and proper versioning. The process is broken down into multiple stages to ensure every change is tracked, reviewed, and integrated appropriately. We use changesets for version and release management.

1. Adding Changes

Whenever you introduce a new change, run the command:

You have to do this at least once per branch with some changes.

npm run changes:add

• The CLI will prompt you with questions regarding your changes. You'll need to specify the nature and level of the changes (options: patch, minor, major).
• After completing the CLI prompts, commit the changes with a commit message similar to chore: update changesets.

2. Releasing and Publishing

Steps to make a release:

• To initiate a release, create a pull request from develop to release with the title Release.
• Ensure all CI checks pass successfully.
• Once CI checks are green and you have at least one approval, merge the pull request.
• Post-merge, the release GitHub Actions will trigger and create an "update versions" pull request to the release branch.
• Wait for the CI to turn green on the "update versions" pull request.
• Once CI is green, merge the "update versions" pull request.
• After this merge, the actions will trigger again. This time, they'll generate a new tag, create a new release, and publish packages to both GitHub and npm registries.

3. Post-Release Activities

After a successful release, ensure you create a backmerge pull request from main to develop. This ensures that the develop branch stays up-to-date with the latest versions and changes.