Can we use Playwright for API Automation Project? Yes!(Part 2)

Greetings to everyone, in this article we will discuss how to run the same tests in different environments. In general, we have different testing environments. These namings can usually be development, staging etc. What I want to talk about here is how the same code we write when running API tests gives results in different environments.Now let’s take a look at how to set up these environments using Playwright.

Playwright Config File Configuration

When you install Playwright in your environment, it provides you with a ready-made config file.The file is usually named “playwright.config.js” or “playwright.config.ts”. This file is the file containing your general configurations in playwright.A simple config file will look like this;

// @ts-check
const { defineConfig, devices } = require("@playwright/test");

/**
 * Read environment variables from file.
 * https://github.com/motdotla/dotenv
 */

/**
 * @see https://playwright.dev/docs/test-configuration
 */
module.exports = defineConfig({
  testDir: "src/tests",
  /* Run tests in files in parallel */
  fullyParallel: true,
  /* Fail the build on CI if you accidentally left test.only in the source code. */
  forbidOnly: !!process.env.CI,
  /* Retry on CI only */
  retries: process.env.CI ? 2 : 0,
  /* Opt out of parallel tests on CI. */
  workers: process.env.CI ? 1 : undefined,
  /* Reporter to use. See https://playwright.dev/docs/test-reporters */
  reporter: "html",
  /* Shared settings for all the projects below. See https://playwright.dev/docs/api/class-testoptions. */
  use: {
    /* Base URL to use in actions like `await page.goto('/')`. */
    baseURL: "https://`{YOUR_BASE_URL}`.com"

    /* Collect trace when retrying the failed test. See https://playwright.dev/docs/trace-viewer */
    trace: "on-first-retry",
  },

  /* Configure projects for major browsers */
  projects: [
    {
      name: "chromium",
      use: {
        ...devices["Desktop Chrome"],
        setup: require.resolve("./authSetup.js"),
      },
    },

    {
      name: 'firefox',
      use: { ...devices['Desktop Firefox'] },
      },

    /* Test against mobile viewports. */
       {
        name: 'Mobile Chrome',
        use: { ...devices['Pixel 5'] },
      },
      {
        name: 'Mobile Safari',
        use: { ...devices['iPhone 12'] },
      },

    /* Test against branded browsers. */
       {
        name: 'Microsoft Edge',
        use: { ...devices['Desktop Edge'], channel: 'msedge' },
      },
      {
        name: 'Google Chrome',
        use: { ...devices['Desktop Chrome'], channel: 'chrome' },
      },
  ],

  /* Run your local dev server before starting the tests */
  // webServer: {
  //   command: 'npm run start',
  //   url: 'http://127.0.0.1:3000',
  //   reuseExistingServer: !process.env.CI,
  // },
});

Let’s say you have a baseURL. Let’s assume that the staging environment is as follows; “https://api.stg.google.com". Let it be like this in the development environment; “https://api.dev.google.com".

Step 1 — Update config file

import { defineConfig } from '@playwright/test';
import dotenv from 'dotenv';
import path from 'path';

// Read .env file
dotenv.config();

export default defineConfig({
  use: {
    baseURL: process.env.NODE_ENV === 'staging' ? 'https://api.stg.google.com' : 'https://api.dev.google.com',
  }
});

Before you make this changes make sure you installed dotenv.

Step 2 — Create .env File

NODE_ENV=staging

Step 3 — Update Your Scripts

You will already have a package.json file. Here we will update the test commands with a small change. Add the scripts below;

"scripts": {
  "test:staging": "NODE_ENV=staging npx playwright test",
  "test:dev": "NODE_ENV=development npx playwright test"
},

This way, you can run tests in the staging environment with the following command:

npm run test:staging

For run your tests in the development environment:

npm run test:dev

Summary

With the minor changes we made above, you can run your API tests in different environments and compare the results. There are different ways to do this. For example, you can prepare more than one config file. For example, config.stg.js and config.dev.js, but I do not know how accurate this approach will be. Because you will make the same definitions again in each file and change only a few lines. I think this would not be a very good method.