Leveraging Playwright for API Testing.pdf

Leveraging Playwright for API Testing
API helps to build the core of any application in the modern software
architecture. They facilitate communication between different systems
and services over the network. Due to their utmost importance, it
becomes very important to ensure that they work as expected and
efficiently handle the different scenarios without breaking.
API Testing is about sending requests to the endpoints and asserting
that the responses are as expected. Different test cases are executed
on the API’s to validate success and error conditions, edge cases,
integration between multiple API’s, performance and security.
To ensure speed, reliability and proper coverage, automation of APIs
can be the right approach to test APIs.

API Basics – CRUD Operations
In API, CRUD functions serve as the basis of any software application.
And testing these operations, viz, Create, Read, Update and
Delete(CRUD) is an essential part of any automation testing
framework. Let us look at what these CRUD operations are-
Create Operations
As can be understood from the name, Create operations are used to
create a resource on the server. Some of the important checkpoints
for create operations are listed below-
● Use the POST or PUT methods to add entities.
● Parameterize values like IDs, names, status codes to validate
different combinations.
● Put assertions to check the response data
● Test various input combinations and boundary values
Read Operations
The Read operations help extract existing data from the server using
the GET Method. Few checkpoints for using the Read Operations are-
● Using pagination and filters to check response
● Validate fields present in response
● Validate for null and invalid parameters
● Assert if response structure matches API documentation
Update Operations
Updates can be made to server resources by using the PATCH or
PUT Methods. Some basic checkpoints to look out for while
performing Update Operations are listed below-

● Sending the updated fields via JSON body
● Validate that the updates are reflected in the response body
● Validation of the status code and response message
● Verification by making the mandatory fields null
● Parameterization to reuse scripts
● Update nested APIs to check logical updates
Delete Operations
Resources can be removed from the server using the DELETE
method. A few points to check while performing the Delete Operations
are listed below-
● Assert response status code 404 or 401 Not Found after
Deletion
● Attempt to delete invalid IDs
● Restoring of deleted entries to reset state
● Parameterization of IDs to be deleted to make reusable scripts
If you ensure that you are covering all the CRUD Operations with the
elaborate test cases, a strong foundation of your application will be
set. Add to it the advantages you would yield with the automation
framework enhancing the test coverage and reusability of the tests.
Benefits of Using Playwright for API Testing
While Playwright is commonly used for browser automation and UI
testing, its capabilities also make it well-suited for testing web APIs.
Some of the advantages are –
● Simplicity and Familiarity of Syntax: Playwright will allow you to
use the same DOM-centric commands(as used in browser
automation) for API Testing.

● Built-in Assertions: You can use assertions to validate the
response status, header, body or the structure.
● You can easily integrate UI and API tests in a single framework.
● Playwright stores and handles cookies and credentials, thereby
maintaining state of execution.
● It supports authentication mechanisms like the basic auth or the
bearer tokens.
● You may use test hooks to mock some API behaviour.
● You can easily scale the existing framework to accommodate
more tests.
● You can easily scale the existing framework to accommodate
more tests.
Prerequisites to Write Playwright API Tests
To start writing the API automation tests using Playwright you need to
ensure that the below mentioned things are installed in your systems-
● Node.js and NPM installed to run playwright
● A code editor like VS Code
● API Documentation
● Some other packages like faker-js, rimraf, etc. These packages
will support your framework by helping you generate test
data(faker-js) and clean up folders(rimraf) before new executions
Let us now jump on to writing our first API test using Playwright.
Writing Playwright API Tests
We will now practically write and execute Playwright API Tests and
refer to dummy APIs of Bookstore. The documentation has multiple
APIs that perform the different CRUD Operations. We will cover
different scenarios starting with POST/PUT methods to:

1. Create a new user using the Register User API.
2. Generate the user token using the Generate Token API.
After the registration and login is done using the Create Operations,
we will use the GET method to:
3. Get the list of available books using the Get Books API.
Set Up
1. We will first create a directory for our Playwright API Test. Open
command prompt and navigate to the folder where you would
want to house your API Test framework. Now, enter the below
command to create a directory:
mkdir playwright_api_test
You will notice in your system that a directory/folder is created:
2. Now open VS Code and then open the project/directory that you
created in Step#1.
3. In the terminal of VS Code enter the below command to install
playwright:
npm init playwright@latest

4. We will now install the helper packages, viz faker-js and rimraf
using below command:
npm install --save-dev @faker-js/faker rimraf
Once the installation of the packages is done, you will notice that
node_modules will be added to project structure with the
dependencies fetched from the packages added to it.

Once the setup is done, we will begin writing our tests. The first step is
to make changes to the configuration file. We will comment out all the

browsers except one and also add our base url to the config file, so
that we simply use the endpoint in our API calls. After the required
updates, the config file should look like below:
// @ts-check
const { defineConfig, devices } = require('@playwright/test');
/**
* Read environment variables from file.
* https://github.com/motdotla/dotenv
*/
// require('dotenv').config();
/**

* @see https://playwright.dev/docs/test-configuration
*/
module.exports = defineConfig({
testDir: './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://bookstore.toolsqa.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'] },
},
/*
{
name: 'firefox',
use: { ...devices['Desktop Firefox'] },
},
{
name: 'webkit',
use: { ...devices['Desktop Safari'] },
},
*/
/* 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,
// },
});
Next, we start writing our first test where we will be using the POST
method to register a user. We will be sending the user data in the
request body as shown in the code below:
const{test, expect} = require('@playwright/test');
test('User registration', async({request})=> {
const response = await request.post("/Account/v1/User",{
data:{
"userName": "gk001",
"password": "gk002@Gk002"
}
});
console.log(await response.json());

});
Execute the code by running the command below-
npx playwright test tests/register_user.spec.js
Upon execution you will see that the test is executed and the test
execution results are displayed in the console:
Now, we will be using the user that we created to generate a token.
Below is code to execute the Generate Token API.
test('Generate Token', async({request})=> {
const response = await request.post("/Account/v1/GenerateToken",{
data:{
"userName": "gk004",
"password": "gk002@Gk002"
}
});
expect(response.status()).toBe(200);

const resBody = await response.json();
expect(resBody).toHaveProperty("result","User authorized
successfully.");
});
You can execute the file in a similar way as we did above, i.e., using
the below command:
npx playwright test tests/generate_token.spec.js
The execution results will be displayed as below:
Our next API will fetch the list of books that are available in the
database. It will use the GET method and code for it is written below.
test('Book List', async({request})=> {
const response = await request.get("/BookStore/v1/Books");
});
Unlike the APIs used in the above two test cases, the GET API will not
have any method body, and here we simply pass the URL endpoint
const response = await request.get("/BookStore/v1/Books");
and validate for the status code to be 200.

You can execute the test case using the below command:
npx playwright test tests/generate_token.spec.js
The execution will show the list of books available in the console logs:
Conclusion
Leveraging Playwright for API testing offers a powerful,
browser-based solution that ensures comprehensive validation, faster
feedback loops, and seamless integration with UI tests for robust
end-to-end automation.
Source: This article was originally published at testgrid.io.

Leveraging Playwright for API Testing.pdf

More Related Content

Similar to Leveraging Playwright for API Testing.pdf (20)

More from Steve Wortham (20)

Recently uploaded (20)

Leveraging Playwright for API Testing.pdf