The Playwright Playbook — Part 4: API Testing — The Underrated Superpower
"The best UI test is one that doesn't need the UI at all."
In Part 1, we built the foundation. In Part 2, we intercepted the network. In Part 3, we ran multiple users simultaneously.
Now we go one layer deeper — below the browser entirely.
Playwright's API request context.
Most engineers reach for Postman when they need to test an API. Or they write a separate pytest/Jest suite just for API tests. Separate tool, separate pipeline, separate maintenance burden.
Here's what they're missing: Playwright can make raw HTTP requests without a browser. Same tool. Same TypeScript. Same test runner. Same CI pipeline.
And when you combine API calls with UI assertions in a single test — that's where the real power shows up.
No browser overhead for setup. No flaky UI login flows for data seeding. Just fast, direct, precise API calls — chained into the UI tests you're already writing.
By the end of this part, you'll have a complete API testing layer that lives right inside your Playwright project. Let's build it. 🎯
🏗️ Where We Left Off
After Part 3, our full project structure is:
playwright-playbook/
├── tests/
│ ├── auth/
│ │ └── login.spec.ts ✅ Part 1
│ ├── tasks/
│ │ └── task-management.spec.ts ✅ Part 1
│ ├── network/ ✅ Part 2
│ │ ├── api-mocking.spec.ts
│ │ ├── error-simulation.spec.ts
│ │ └── network-assertions.spec.ts
│ ├── multi-user/ ✅ Part 3
│ │ ├── role-permissions.spec.ts
│ │ └── realtime-collaboration.spec.ts
│ └── multi-tab/ ✅ Part 3
│ └── multi-tab-flows.spec.ts
├── pages/
│ ├── LoginPage.ts ✅ Part 1
│ ├── TaskPage.ts ✅ Part 1
│ └── DashboardPage.ts ✅ Part 3
├── fixtures/
│ ├── auth.fixture.ts ✅ Part 1
│ ├── tasks.json ✅ Part 2
│ ├── empty-tasks.json ✅ Part 2
│ ├── tasks-har.har ✅ Part 2
│ └── multi-user.fixture.ts ✅ Part 3
├── scripts/
│ └── record-har.ts ✅ Part 2
├── .auth/
│ ├── admin.json
│ └── user.json
├── global-setup.ts ✅ Part 1
├── playwright.config.ts ✅ Part 1 (updated Part 3)
└── .env
By the end of Part 4, we add:
playwright-playbook/
├── tests/
│ └── api/ ← NEW
│ ├── tasks-api.spec.ts
│ ├── auth-api.spec.ts
│ ├── graphql-api.spec.ts
│ └── api-ui-chain.spec.ts
├── api/ ← NEW
│ ├── TaskApiClient.ts
│ └── AuthApiClient.ts
├── fixtures/
│ └── api.fixture.ts ← NEW
└── utils/
└── schema-validator.ts ← NEW
Every one of these files gets fully built below. Let's go. 👇
🧠 The Mental Model — Three Ways to Use the Request Context
Before we write code, understand the three modes Playwright gives you for API testing:
Mode 1 — request fixture (isolated, no browser cookies)
└── Pure API tests — no UI involved at all
Mode 2 — page.request (shares browser context cookies)
└── API calls that need the same auth as the current page
Mode 3 — APIRequestContext from playwright.config.ts
└── Shared request context across your whole suite (baseURL, headers)
We'll use all three — each for the right job. Let's build from the bottom up.
⚙️ Configuring the API Base in playwright.config.ts
First, add API-specific config so all our API clients share the same base settings:
// playwright.config.ts — updated
import { defineConfig, devices } from '@playwright/test';
import * as dotenv from 'dotenv';
dotenv.config();
export default defineConfig({
testDir: './tests',
fullyParallel: true,
forbidOnly: !!process.env.CI,
retries: process.env.CI ? 1 : 0,
workers: process.env.CI ? 4 : undefined,
globalSetup: './global-setup.ts',
reporter: [
['html', { open: 'never' }],
['list'],
],
use: {
baseURL: process.env.BASE_URL || 'http://localhost:3000',
screenshot: 'only-on-failure',
video: 'retain-on-failure',
trace: 'on-first-retry',
// Default headers for ALL API requests across the suite
extraHTTPHeaders: {
'Accept': 'application/json',
'Content-Type': 'application/json',
},
},
projects: [
{
name: 'admin',
use: {
...devices['Desktop Chrome'],
storageState: '.auth/admin.json',
},
testMatch: ['**/auth/**', '**/tasks/**', '**/network/**'],
},
{
name: 'user',
use: {
...devices['Desktop Chrome'],
storageState: '.auth/user.json',
},
testMatch: ['**/tasks/**'],
},
{
name: 'multi-context',
use: { ...devices['Desktop Chrome'] },
testMatch: ['**/multi-user/**', '**/multi-tab/**'],
},
{
// API tests — no browser needed, no storageState
name: 'api',
use: {},
testMatch: ['**/api/**'],
},
],
});
The api project has no devices — no browser spins up at all for pure API tests. Fastest possible execution. ✅
🔑 Building the Auth API Client
Our Task Manager uses JWT tokens. Before we can call protected API endpoints, we need a way to get tokens programmatically — without touching the browser.
// api/AuthApiClient.ts
import { APIRequestContext } from '@playwright/test';
export interface AuthTokens {
accessToken: string;
refreshToken: string;
expiresIn: number;
}
export interface UserCredentials {
email: string;
password: string;
}
export class AuthApiClient {
constructor(private readonly request: APIRequestContext) {}
async login(credentials: UserCredentials): Promise<AuthTokens> {
const response = await this.request.post('/api/auth/login', {
data: credentials,
});
if (!response.ok()) {
throw new Error(
`Login failed: ${response.status()}${await response.text()}`
);
}
return response.json() as Promise<AuthTokens>;
}
async refreshToken(refreshToken: string): Promise<AuthTokens> {
const response = await this.request.post('/api/auth/refresh', {
data: { refreshToken },
});
if (!response.ok()) {
throw new Error(`Token refresh failed: ${response.status()}`);
}
return response.json() as Promise<AuthTokens>;
}
async logout(accessToken: string): Promise<void> {
await this.request.post('/api/auth/logout', {
headers: { Authorization: `Bearer ${accessToken}` },
});
}
async getAdminToken(): Promise<string> {
const tokens = await this.login({
email: process.env.ADMIN_EMAIL!,
password: process.env.ADMIN_PASSWORD!,
});
return tokens.accessToken;
}
async getUserToken(): Promise<string> {
const tokens = await this.login({
email: process.env.USER_EMAIL!,
password: process.env.USER_PASSWORD!,
});
return tokens.accessToken;
}
}
📋 Building the Task API Client
Now the main API client — wrapping all task-related endpoints with typed methods.
// api/TaskApiClient.ts
import { APIRequestContext, APIResponse } from '@playwright/test';
export interface Task {
id: number;
title: string;
status: 'pending' | 'in_progress' | 'completed';
assignee: string;
createdAt: string;
updatedAt: string;
}
export interface CreateTaskPayload {
title: string;
status?: Task['status'];
assignee?: string;
}
export interface UpdateTaskPayload {
title?: string;
status?: Task['status'];
assignee?: string;
}
export class TaskApiClient {
constructor(
private readonly request: APIRequestContext,
private readonly token: string
) {}
private get authHeaders() {
return { Authorization: `Bearer ${this.token}` };
}
async getAllTasks(): Promise<Task[]> {
const response = await this.request.get('/api/tasks', {
headers: this.authHeaders,
});
return response.json();
}
async getTask(id: number): Promise<Task> {
const response = await this.request.get(`/api/tasks/${id}`, {
headers: this.authHeaders,
});
return response.json();
}
async createTask(payload: CreateTaskPayload): Promise<{ response: APIResponse; task: Task }> {
const response = await this.request.post('/api/tasks', {
headers: this.authHeaders,
data: payload,
});
const task = await response.json();
return { response, task };
}
async updateTask(id: number, payload: UpdateTaskPayload): Promise<{ response: APIResponse; task: Task }> {
const response = await this.request.patch(`/api/tasks/${id}`, {
headers: this.authHeaders,
data: payload,
});
const task = await response.json();
return { response, task };
}
async deleteTask(id: number): Promise<APIResponse> {
return this.request.delete(`/api/tasks/${id}`, {
headers: this.authHeaders,
});
}
async getTasksByStatus(status: Task['status']): Promise<Task[]> {
const response = await this.request.get(`/api/tasks?status=${status}`, {
headers: this.authHeaders,
});
return response.json();
}
}
Fully typed. Every method returns the raw APIResponse where needed (so tests can assert on status codes) AND the parsed body. No hunting through raw responses in test files. 🎯
🧩 Building the API Fixture
Just like Part 1's auth.fixture.ts made POM setup invisible in tests, our api.fixture.ts makes API client setup invisible.
// fixtures/api.fixture.ts
import { test as base, APIRequestContext } from '@playwright/test';
import { TaskApiClient } from '../api/TaskApiClient';
import { AuthApiClient } from '../api/AuthApiClient';
type ApiFixtures = {
authApi: AuthApiClient;
adminTaskApi: TaskApiClient;
userTaskApi: TaskApiClient;
};
export const test = base.extend<ApiFixtures>({
// Auth API client — unauthenticated, used for login/logout tests
authApi: async ({ request }, use) => {
await use(new AuthApiClient(request));
},
// Task API client — authenticated as admin
adminTaskApi: async ({ request }, use) => {
const authApi = new AuthApiClient(request);
const token = await authApi.getAdminToken();
await use(new TaskApiClient(request, token));
},
// Task API client — authenticated as regular user
userTaskApi: async ({ request }, use) => {
const authApi = new AuthApiClient(request);
const token = await authApi.getUserToken();
await use(new TaskApiClient(request, token));
},
});
export { expect } from '@playwright/test';
🛡️ Building the Schema Validator
One of the most common API testing gaps: everyone checks status codes, almost nobody validates response structure. A 200 with a broken body is still a broken API.
// utils/schema-validator.ts
export interface TaskSchema {
id: number;
title: string;
status: string;
assignee: string;
createdAt: string;
updatedAt: string;
}
export function validateTaskSchema(task: unknown): task is TaskSchema {
if (typeof task !== 'object' || task === null) return false;
const t = task as Record<string, unknown>;
return (
typeof t.id === 'number' &&
typeof t.title === 'string' &&
t.title.length > 0 &&
['pending', 'in_progress', 'completed'].includes(t.status as string) &&
typeof t.assignee === 'string' &&
typeof t.createdAt === 'string' &&
typeof t.updatedAt === 'string' &&
!isNaN(Date.parse(t.createdAt as string)) &&
!isNaN(Date.parse(t.updatedAt as string))
);
}
export function validateTaskListSchema(tasks: unknown): tasks is TaskSchema[] {
return Array.isArray(tasks) && tasks.every(validateTaskSchema);
}
// Generic field presence checker — useful for partial response validation
export function assertRequiredFields(
obj: Record<string, unknown>,
fields: string[]
): void {
const missing = fields.filter(field => !(field in obj) || obj[field] === undefined);
if (missing.length > 0) {
throw new Error(`Missing required fields in response: ${missing.join(', ')}`);
}
}
✅ Task API Tests — CRUD, Status Codes & Schema Validation
// tests/api/tasks-api.spec.ts
import { test, expect } from '../../fixtures/api.fixture';
import { validateTaskSchema, validateTaskListSchema } from '../../utils/schema-validator';
test.describe('Tasks API — GET', () => {
test('GET /api/tasks returns 200 and valid task list schema', async ({ adminTaskApi }) => {
const tasks = await adminTaskApi.getAllTasks();
expect(Array.isArray(tasks)).toBe(true);
expect(validateTaskListSchema(tasks)).toBe(true);
});
test('GET /api/tasks/:id returns correct task', async ({ adminTaskApi }) => {
// Create a task first so we have a known ID
const { task: created } = await adminTaskApi.createTask({
title: 'Schema validation test task',
});
const fetched = await adminTaskApi.getTask(created.id);
expect(fetched.id).toBe(created.id);
expect(fetched.title).toBe('Schema validation test task');
expect(validateTaskSchema(fetched)).toBe(true);
// Cleanup
await adminTaskApi.deleteTask(created.id);
});
test('GET /api/tasks/:id returns 404 for non-existent task', async ({ request }) => {
// Use raw request here since TaskApiClient throws on non-ok responses
const response = await request.get('/api/tasks/999999', {
headers: { Authorization: `Bearer ${process.env.ADMIN_TOKEN}` },
});
expect(response.status()).toBe(404);
const body = await response.json();
expect(body).toHaveProperty('error');
});
test('GET /api/tasks filters by status correctly', async ({ adminTaskApi }) => {
const completedTasks = await adminTaskApi.getTasksByStatus('completed');
expect(Array.isArray(completedTasks)).toBe(true);
completedTasks.forEach(task => {
expect(task.status).toBe('completed');
});
});
});
test.describe('Tasks API — POST', () => {
test('POST /api/tasks creates task and returns 201', async ({ adminTaskApi }) => {
const { response, task } = await adminTaskApi.createTask({
title: 'New API test task',
status: 'pending',
});
// Status code
expect(response.status()).toBe(201);
// Response body
expect(task.title).toBe('New API test task');
expect(task.status).toBe('pending');
expect(task.id).toBeDefined();
expect(typeof task.id).toBe('number');
// Full schema
expect(validateTaskSchema(task)).toBe(true);
// Cleanup
await adminTaskApi.deleteTask(task.id);
});
test('POST /api/tasks with missing title returns 400', async ({ request }) => {
const response = await request.post('/api/tasks', {
headers: {
Authorization: `Bearer ${process.env.ADMIN_TOKEN}`,
'Content-Type': 'application/json',
},
data: { status: 'pending' }, // no title
});
expect(response.status()).toBe(400);
const body = await response.json();
expect(body.error).toContain('title');
});
test('POST /api/tasks without auth returns 401', async ({ request }) => {
const response = await request.post('/api/tasks', {
data: { title: 'Unauthorized task' },
// No Authorization header
});
expect(response.status()).toBe(401);
});
});
test.describe('Tasks API — PATCH', () => {
test('PATCH /api/tasks/:id updates task correctly', async ({ adminTaskApi }) => {
// Create
const { task: created } = await adminTaskApi.createTask({
title: 'Task to update',
status: 'pending',
});
// Update
const { response, task: updated } = await adminTaskApi.updateTask(created.id, {
status: 'completed',
title: 'Updated task title',
});
expect(response.status()).toBe(200);
expect(updated.status).toBe('completed');
expect(updated.title).toBe('Updated task title');
expect(updated.id).toBe(created.id); // ID should never change
expect(updated.updatedAt).not.toBe(created.updatedAt); // timestamp should change
// Cleanup
await adminTaskApi.deleteTask(created.id);
});
test('regular user cannot update another user\'s task', async ({
adminTaskApi,
userTaskApi,
}) => {
// Admin creates a task
const { task } = await adminTaskApi.createTask({
title: 'Admin task — user should not update',
});
// User tries to update it
const { response } = await userTaskApi.updateTask(task.id, {
title: 'Hijacked title',
});
expect(response.status()).toBe(403);
// Cleanup
await adminTaskApi.deleteTask(task.id);
});
});
test.describe('Tasks API — DELETE', () => {
test('DELETE /api/tasks/:id returns 200 and task no longer exists', async ({
adminTaskApi,
}) => {
const { task } = await adminTaskApi.createTask({ title: 'Task to delete via API' });
const deleteResponse = await adminTaskApi.deleteTask(task.id);
expect(deleteResponse.status()).toBe(200);
// Try to fetch the deleted task — should be 404
const tasks = await adminTaskApi.getAllTasks();
const stillExists = tasks.find(t => t.id === task.id);
expect(stillExists).toBeUndefined();
});
test('regular user cannot delete admin task — returns 403', async ({
adminTaskApi,
userTaskApi,
}) => {
const { task } = await adminTaskApi.createTask({ title: 'Protected admin task' });
const deleteResponse = await userTaskApi.deleteTask(task.id);
expect(deleteResponse.status()).toBe(403);
// Cleanup as admin
await adminTaskApi.deleteTask(task.id);
});
});
🔐 Auth API Tests — Token Flows & Security
// tests/api/auth-api.spec.ts
import { test, expect } from '../../fixtures/api.fixture';
test('successful login returns valid token structure', async ({ authApi }) => {
const tokens = await authApi.login({
email: process.env.USER_EMAIL!,
password: process.env.USER_PASSWORD!,
});
expect(typeof tokens.accessToken).toBe('string');
expect(tokens.accessToken.length).toBeGreaterThan(0);
expect(typeof tokens.refreshToken).toBe('string');
expect(typeof tokens.expiresIn).toBe('number');
expect(tokens.expiresIn).toBeGreaterThan(0);
});
test('invalid credentials return 401', async ({ request }) => {
const response = await request.post('/api/auth/login', {
data: {
email: 'notauser@test.com',
password: 'wrongpassword',
},
});
expect(response.status()).toBe(401);
const body = await response.json();
expect(body).toHaveProperty('error');
});
test('expired or invalid token returns 401 on protected route', async ({ request }) => {
const response = await request.get('/api/tasks', {
headers: {
Authorization: 'Bearer this.is.not.a.valid.token',
},
});
expect(response.status()).toBe(401);
});
test('refresh token returns new access token', async ({ authApi }) => {
// Login to get tokens
const initial = await authApi.login({
email: process.env.USER_EMAIL!,
password: process.env.USER_PASSWORD!,
});
// Use refresh token to get a new access token
const refreshed = await authApi.refreshToken(initial.refreshToken);
expect(typeof refreshed.accessToken).toBe('string');
// New access token should be different from the original
expect(refreshed.accessToken).not.toBe(initial.accessToken);
});
test('logout invalidates the token', async ({ authApi, request }) => {
// Login
const tokens = await authApi.login({
email: process.env.USER_EMAIL!,
password: process.env.USER_PASSWORD!,
});
// Logout
await authApi.logout(tokens.accessToken);
// Try to use the token after logout — should be rejected
const response = await request.get('/api/tasks', {
headers: { Authorization: `Bearer ${tokens.accessToken}` },
});
expect(response.status()).toBe(401);
});
🔷 GraphQL API Tests
Many modern apps expose a GraphQL API alongside (or instead of) REST. Playwright handles it just as cleanly — GraphQL is just a POST to one endpoint.
// tests/api/graphql-api.spec.ts
import { test, expect } from '../../fixtures/api.fixture';
import { validateTaskSchema } from '../../utils/schema-validator';
// Helper to fire a GraphQL query/mutation
async function gql(
request: import('@playwright/test').APIRequestContext,
token: string,
query: string,
variables?: Record<string, unknown>
) {
const response = await request.post('/graphql', {
headers: {
Authorization: `Bearer ${token}`,
'Content-Type': 'application/json',
},
data: { query, variables },
});
return response;
}
test('GraphQL query — fetch all tasks', async ({ request, authApi }) => {
const token = await authApi.getAdminToken();
const response = await gql(request, token, `
query GetTasks {
tasks {
id
title
status
assignee
createdAt
updatedAt
}
}
`);
expect(response.status()).toBe(200);
const body = await response.json();
expect(body).not.toHaveProperty('errors');
expect(Array.isArray(body.data.tasks)).toBe(true);
expect(validateTaskSchema(body.data.tasks[0])).toBe(true);
});
test('GraphQL mutation — create task', async ({ request, authApi }) => {
const token = await authApi.getAdminToken();
const response = await gql(
request,
token,
`
mutation CreateTask($title: String!, $status: TaskStatus) {
createTask(title: $title, status: $status) {
id
title
status
createdAt
}
}
`,
{ title: 'GraphQL created task', status: 'PENDING' }
);
expect(response.status()).toBe(200);
const body = await response.json();
expect(body).not.toHaveProperty('errors');
expect(body.data.createTask.title).toBe('GraphQL created task');
expect(body.data.createTask.id).toBeDefined();
});
test('GraphQL returns errors array on bad query — not HTTP error', async ({
request,
authApi,
}) => {
const token = await authApi.getAdminToken();
// GraphQL always returns 200 — errors live in the body
const response = await gql(request, token, `
query {
nonExistentField {
id
}
}
`);
expect(response.status()).toBe(200); // ← this is the GraphQL gotcha
const body = await response.json();
expect(body).toHaveProperty('errors');
expect(Array.isArray(body.errors)).toBe(true);
});
The last test is important — it catches the GraphQL testing gotcha that trips up most engineers. GraphQL almost always returns HTTP 200, even for errors. The actual error lives in body.errors. If you're only asserting on the status code, you'll miss half your bugs. 🎯
🔗 Chaining API + UI — The Most Powerful Pattern
This is the pattern that makes your entire test suite faster and more reliable.
The idea: Use the API to set up test data (fast, no UI overhead) — then use the UI to assert on what the user actually sees. Or flip it — interact via UI, then validate what hit the database via API.
// tests/api/api-ui-chain.spec.ts
import { test, expect } from '@playwright/test';
import { TaskApiClient } from '../../api/TaskApiClient';
import { AuthApiClient } from '../../api/AuthApiClient';
import { TaskPage } from '../../pages/TaskPage';
import { validateTaskSchema } from '../../utils/schema-validator';
test('seed task via API — verify it appears in UI', async ({ page, request }) => {
// Step 1 — Get token and create task via API (fast, no browser)
const authApi = new AuthApiClient(request);
const token = await authApi.getAdminToken();
const taskApi = new TaskApiClient(request, token);
const { task } = await taskApi.createTask({
title: 'API-seeded task for UI verification',
status: 'pending',
});
// Step 2 — Navigate to UI and verify the task is visible
const taskPage = new TaskPage(page);
await taskPage.goto();
await expect(
taskPage.getTaskLocator('API-seeded task for UI verification')
).toBeVisible();
// Cleanup via API — no UI overhead for teardown either
await taskApi.deleteTask(task.id);
});
test('create task via UI — verify it hit the API correctly', async ({
page,
request,
}) => {
const taskPage = new TaskPage(page);
await taskPage.goto();
// Listen for the POST and capture what was sent
let capturedTaskId: number | null = null;
const [response] = await Promise.all([
page.waitForResponse(
resp =>
resp.url().includes('/api/tasks') &&
resp.request().method() === 'POST' &&
resp.status() === 201
),
taskPage.createTask('UI-created task — verify via API'),
]);
const createdTask = await response.json();
capturedTaskId = createdTask.id;
// Now verify via API that the correct data was persisted
const authApi = new AuthApiClient(request);
const token = await authApi.getAdminToken();
const taskApi = new TaskApiClient(request, token);
const fetchedTask = await taskApi.getTask(capturedTaskId!);
expect(fetchedTask.title).toBe('UI-created task — verify via API');
expect(fetchedTask.status).toBe('pending');
expect(validateTaskSchema(fetchedTask)).toBe(true);
// Cleanup
await taskApi.deleteTask(capturedTaskId!);
});
test('bulk seed via API — UI pagination works correctly', async ({
page,
request,
}) => {
const authApi = new AuthApiClient(request);
const token = await authApi.getAdminToken();
const taskApi = new TaskApiClient(request, token);
// Create 25 tasks via API — in parallel for speed
const createdTasks = await Promise.all(
Array.from({ length: 25 }, (_, i) =>
taskApi.createTask({ title: `Pagination test task ${i + 1}` })
)
);
// Navigate to UI and check pagination renders correctly
const taskPage = new TaskPage(page);
await taskPage.goto();
// First page should show page size (assuming 10 per page)
await expect(page.getByRole('listitem')).toHaveCount(10);
await expect(page.getByTestId('pagination')).toBeVisible();
await expect(page.getByTestId('total-count')).toContainText('25');
// Cleanup all created tasks via API in parallel
await Promise.all(
createdTasks.map(({ task }) => taskApi.deleteTask(task.id))
);
});
test('delete via UI — confirm gone via API', async ({ page, request }) => {
// Seed task via API
const authApi = new AuthApiClient(request);
const token = await authApi.getAdminToken();
const taskApi = new TaskApiClient(request, token);
const { task } = await taskApi.createTask({
title: 'Task to delete from UI',
});
// Delete via UI
const taskPage = new TaskPage(page);
await taskPage.goto();
await taskPage.deleteTask('Task to delete from UI');
// Confirm UI updated
await expect(taskPage.getTaskLocator('Task to delete from UI')).not.toBeVisible();
// Confirm API also reflects deletion
const allTasks = await taskApi.getAllTasks();
const stillExists = allTasks.find(t => t.id === task.id);
expect(stillExists).toBeUndefined();
});
This is the pattern that catches the bugs your pure UI tests miss — when the UI says something is deleted but the database still has it. Or when the UI shows a task but the API returns it with wrong data. Catching the gap between what the user sees and what actually happened is where this shines. 🔥
📁 Final Project Structure After Part 4
Every file listed below has been fully built across Parts 1 through 4:
playwright-playbook/
├── tests/
│ ├── auth/
│ │ └── login.spec.ts ✅ Part 1
│ ├── tasks/
│ │ └── task-management.spec.ts ✅ Part 1
│ ├── network/ ✅ Part 2
│ │ ├── api-mocking.spec.ts
│ │ ├── error-simulation.spec.ts
│ │ └── network-assertions.spec.ts
│ ├── multi-user/ ✅ Part 3
│ │ ├── role-permissions.spec.ts
│ │ └── realtime-collaboration.spec.ts
│ ├── multi-tab/ ✅ Part 3
│ │ └── multi-tab-flows.spec.ts
│ └── api/ ✅ Part 4
│ ├── tasks-api.spec.ts
│ ├── auth-api.spec.ts
│ ├── graphql-api.spec.ts
│ └── api-ui-chain.spec.ts
├── pages/
│ ├── LoginPage.ts ✅ Part 1
│ ├── TaskPage.ts ✅ Part 1
│ └── DashboardPage.ts ✅ Part 3
├── api/ ✅ Part 4
│ ├── TaskApiClient.ts
│ └── AuthApiClient.ts
├── fixtures/
│ ├── auth.fixture.ts ✅ Part 1
│ ├── tasks.json ✅ Part 2
│ ├── empty-tasks.json ✅ Part 2
│ ├── tasks-har.har ✅ Part 2
│ ├── multi-user.fixture.ts ✅ Part 3
│ └── api.fixture.ts ✅ Part 4
├── scripts/
│ └── record-har.ts ✅ Part 2
├── utils/ ✅ Part 4
│ └── schema-validator.ts
├── .auth/ ← git-ignored
│ ├── admin.json
│ └── user.json
├── global-setup.ts ✅ Part 1
├── playwright.config.ts ✅ Part 1 (updated Parts 3 & 4)
├── .env ← git-ignored
└── package.json
🗺️ What's Coming in This Series
Part 1 — Stop Writing Tests Like a Beginner ✅ Done
Part 2 — Network Interception: The Complete Guide ✅ Done
Part 3 — Multi-User, Multi-Tab & Context Testing ✅ Done
Part 4 — API Testing (The Underrated Superpower) ← You are here
Part 5 — Visual Regression Testing
Part 6 — Debugging Like a Pro: Trace Viewer & Inspector
Part 7 — The CI/CD Setup Nobody Shows You
Part 8 — Playwright Meets AI: Agents, MCP & Self-Healing Tests
In Part 5, we add visual regression testing — toHaveScreenshot(), masking dynamic content, pixel tolerance config, and running VRT in CI without flakiness. The kind of bugs that slip past every assertion you've written so far.
🔖 Before You Go
After four parts, you've built something real:
- A POM-based UI test layer with proper auth
- A network interception layer that owns the API at the browser level
- A multi-user layer that tests collaboration and permissions simultaneously
- A raw API testing layer with typed clients, schema validation, and API-UI chaining
Each layer is independent. Each layer builds on the last.
And you've done it all in one tool, one language, one pipeline. No Postman. No separate pytest suite. No context switching. 💪
Follow me so you don't miss Part 5 — where we catch the bugs that slip past every assertion: CSS regressions, layout shifts, and design inconsistencies — with Playwright's visual regression testing.
Drop a comment below 👇
- Are you currently running API tests in a separate tool from your UI tests?
- Did the GraphQL gotcha (200 status with errors in body) catch you off guard?
- What's the first API endpoint you'd write a schema validation test for?
Let's talk in the comments. 🙌
Faizal Shaikh | Senior Automation Engineer | Playwright & AI Testing
Connect with me on LinkedIn
For further actions, you may consider blocking this person and/or reporting abuse
