Part 6: API Models, Schema Validation & Test Data Management in Playwright

Introduction

In the previous chapter, we built an enterprise-level Playwright API framework using API Clients, Service Layers, Base API Clients, and a Request Manager. Our framework is already much cleaner than a beginner-level project.

However, there's still one major problem. Most beginners continue to send raw JSON objects directly inside their tests.

await userService.createUser({
    firstName: "John",
    lastName: "Doe",
    email: "john@test.com"
});

This approach works for small projects, but as your automation suite grows, it becomes difficult to maintain. Imagine an API with 40 fields. Now imagine that API is used in 300 different test cases. If the backend team changes a single field name, you'll have to update hundreds of tests.

Enterprise automation teams solve this problem using Request Models, Response Models, Schema Validation, and Test Data Factories. By the end of this chapter, you'll learn how to build a type-safe, maintainable Playwright framework that can scale to thousands of API tests.

Why Models Matter

Models represent the structure of your API data. Instead of passing anonymous JSON objects everywhere, you define reusable interfaces or classes.

For example, instead of writing:

{
    firstName:"John",
    lastName:"Doe",
    email:"john@test.com"
}

Create a reusable model.

export interface User{
    firstName:string;
    lastName:string;
    email:string;
}

Now every test uses the same structure. This improves readability, type safety, IntelliSense, and maintainability.

Request Models

A Request Model represents data sent to an API.

export interface CreateUserRequest{
    firstName:string;
    lastName:string;
    email:string;
    password:string;
}

Now your service becomes:

const request:CreateUserRequest={
    firstName:"John",
    lastName:"Doe",
    email:"john@test.com",
    password:"Password123"
};

await userService.createUser(request);

Notice how much cleaner this is compared to using anonymous JSON objects.

Response Models

Response Models describe what your application returns.

export interface UserResponse{
    id:number;
    firstName:string;
    lastName:string;
    email:string;
    createdAt:string;
}

Now your response becomes strongly typed.

const user:UserResponse=
await response.json();

Your IDE now provides auto-complete, type checking, and better code navigation.

Organizing Models

A professional project separates models by feature.

src/
  models/
    users/
      CreateUserRequest.ts
      UpdateUserRequest.ts
      UserResponse.ts
    products/
    orders/
    payments/

Avoid placing every model into one giant file. Feature-based organization is much easier to maintain.

Why Response Validation Matters

Many beginners validate only:

expect(response.status()).toBe(200);

This is not enough. Imagine the backend accidentally changes:

{
   "email":"john@test.com"
}

to:

{
   "userEmail":"john@test.com"
}

The API still returns 200 OK. Your UI may completely break. But your automation test still passes. That's dangerous.

Professional automation engineers validate the structure of every important response.

Introducing Schema Validation

Schema Validation verifies that an API response matches an expected structure. Instead of checking one or two fields, the entire payload is validated.

Expected structure:

User
├── id
├── firstName
├── lastName
├── email
└── createdAt

If even one required property is missing, the test fails immediately.

Using Zod for Schema Validation

One of the best libraries for Playwright API testing is Zod. Install it:

npm install zod

Create a schema.

import { z } from "zod";

export const UserSchema = z.object({
    id: z.number(),
    firstName: z.string(),
    lastName: z.string(),
    email: z.string().email(),
    createdAt: z.string()
});

Now validate the response.

const body=await response.json();

UserSchema.parse(body);

If the response doesn't match the schema, the test fails immediately.

Benefits of Schema Validation

Schema validation catches problems such as:

• Missing fields
• Incorrect data types
• Null values
• Invalid email addresses
• Unexpected properties

It provides much stronger validation than checking only status codes.

Creating Test Data Factories

Hardcoding data inside tests creates maintenance headaches. Bad example:

const user={
   firstName:"John",
   lastName:"Doe",
   email:"john@test.com"
}

Instead, create reusable factories.

export class UserFactory{
    static create(){
        return{
            firstName:"John",
            lastName:"Doe",
            email:"john@test.com",
            password:"Password123"
        };
    }
}

Now every test simply calls:

const user=UserFactory.create();

This keeps test data centralized and reusable.

Generating Dynamic Test Data

Enterprise APIs often reject duplicate values. Instead of using fixed emails, generate dynamic data.

const email=
`user${Date.now()}@test.com`;

Or use a data generation library such as Faker.

import { faker } from "@faker-js/faker";

const email=faker.internet.email();

Dynamic test data makes your tests more reliable and reduces conflicts.

Request Builders

Large enterprise APIs often require dozens of request fields. Rather than manually constructing objects, use a Request Builder.

const request=
new UserRequestBuilder()
.setFirstName("John")
.setLastName("Doe")
.setEmail("john@test.com")
.build();

Benefits include better readability, fluent syntax, easier maintenance, and optional field handling.

Validating Business Rules

Schema validation verifies structure. Business validation verifies behavior.

Instead of only checking:

expect(response.status()).toBe(201);

Also verify:

• Customer ID generated
• Account status is ACTIVE
• Balance equals expected amount
• User role is ADMIN
• Expiration date exists

Business validation ensures your application behaves correctly.

Organizing Test Data

A professional project keeps test data separate from test logic.

data/
  users/
    admin.json
    customer.json
    guest.json
  products/
  orders/

Benefits include reusability, cleaner tests, easier updates, and environment independence.

Enterprise Best Practices

Experienced SDETs typically follow these guidelines:

• Create request models.
• Create response models.
• Validate API schemas.
• Use reusable data factories.
• Generate dynamic test data.
• Keep test data outside test files.
• Validate business rules in addition to response schemas.

Following these practices results in a scalable and maintainable automation framework.

Common Beginner Mistakes

Avoid these common mistakes:

• Hardcoding request payloads.
• Validating only status codes.
• Ignoring response structure.
• Repeating test data.
• Copy-pasting JSON across tests.
• Mixing test data with business logic.

As your project grows, these issues become increasingly difficult to manage.

Interview Questions

Why should API responses be validated using schemas?

Schema validation ensures the API response structure matches the expected contract. It helps detect breaking changes, missing fields, incorrect data types, and malformed payloads before they affect UI automation or downstream systems.

What is the difference between Request Models and Response Models?

Request Models define the structure of data sent to an API. Response Models define the structure of data returned by an API. Separating them improves readability, type safety, and maintainability.

Why should automation frameworks use Test Data Factories?

Test Data Factories centralize reusable test data, reduce duplication, simplify maintenance, and allow easy generation of dynamic or randomized test inputs for different scenarios.

Summary

Excellent progress! Your Playwright API automation framework is becoming increasingly professional and maintainable.

In this chapter, you learned:

• Request Models
• Response Models
• Organizing Models
• Schema Validation
• Zod Integration
• Test Data Factories
• Dynamic Test Data
• Request Builders
• Business Rule Validation
• Enterprise Test Data Management
• Common mistakes to avoid

At this point, your framework follows many of the same design principles used by enterprise QA teams.

In Part 7, we'll take the framework to the next level by implementing API Hooks, Global Setup & Teardown, Custom Fixtures, Request/Response Logging, Retry Strategies, Error Handling, and Parallel Execution, making the framework robust enough for CI/CD pipelines and large-scale enterprise automation projects.