Using Playwright with TypeScript

Type-Safe Test Configuration

Using TypeScript for your Playwright configuration allows you to define complex objects with strict structural requirements. When you define your config file with the 'defineConfig' helper, the editor provides full IDE support, ensuring you never misspell a property or provide an invalid data type for timeout settings, project structures, or reporter configurations. Because the configuration is a TypeScript object, the compiler validates your setup before any tests are executed, preventing failure mid-test due to a typo in your base URL or browser launch options. This static verification is crucial for enterprise-level automation where configuration drift can cause intermittent failures. By explicitly typing your environment settings, you guarantee that every developer on your team adheres to the same structure, reducing the cognitive overhead of onboarding new contributors who may not know the full list of available properties by heart.

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

// Defining the config with types ensures structural integrity
export default defineConfig({
  timeout: 30000, // 30 seconds limit for each test
  use: {
    baseURL: 'https://api.myapp.com',
    browserName: 'chromium',
  },
  reporter: [['list'], ['json', { outputFile: 'results.json' }]],
});

Interface-Driven Page Object Models

Page Object Models (POMs) represent the core of a maintainable automation strategy. By defining an interface for your page components, you establish a contract that must be fulfilled by the implementation. This enforces consistency: if you rename a selector in your interface, the compiler immediately flags every test that relies on that specific element, preventing runtime 'undefined' errors when you attempt to interact with non-existent buttons or input fields. The interface also acts as documentation for other developers, clearly outlining which actions—like 'login' or 'navigateToSettings'—are publicly available on a specific page. By leveraging class members with explicit access modifiers, you can encapsulate private helper methods, ensuring that external tests only interact with the high-level API you intend to expose, thus maintaining a clean abstraction layer and minimizing the surface area for bugs.

interface LoginPageInterface {
  login(user: string, pass: string): Promise<void>;
}

export class LoginPage implements LoginPageInterface {
  constructor(private page: Page) {}

  async login(user: string, pass: string) {
    await this.page.fill('#username', user); // Internal implementation hidden
    await this.page.fill('#password', pass);
    await this.page.click('button[type="submit"]');
  }
}

Strict Typing for Test Fixtures

Fixtures allow for custom setup and teardown logic, but managing them in large projects can become chaotic without type safety. By extending the base test object with custom types, you create a 'service container' where your utility functions, database helpers, or mock APIs are automatically typed and injected into tests. When you define a fixture, you provide a type signature that ensures the data being passed is exactly what the test expects. This eliminates the need for manual casting or defensive programming checks inside your test bodies. If a helper returns a 'User' object, you gain immediate autocompletion for that user's properties. This strong coupling between the fixture definition and the test context ensures that if the schema of your backend changes, your tests fail at compile time rather than failing sporadically in the CI environment with cryptic null pointer exceptions.

import { test as base } from '@playwright/test';

// Custom type for fixture data
interface TestFixtures {
  authenticatedPage: Page;
}

// Extend base test to include our custom type
export const test = base.extend<TestFixtures>({
  authenticatedPage: async ({ page }, use) => {
    await page.goto('/login');
    await use(page); // Provide the authenticated page instance
  },
});

Handling API Responses with Enums

When dealing with API responses, using magic strings is a common source of fragile code. TypeScript enums allow you to define a set of named constants that represent status codes or response types. This prevents errors caused by simple typos in status string comparisons. For instance, instead of checking if a response status equals 'SUCCESS', you use the enum value, which the compiler validates. This is vital when consuming dynamic API data within your tests, as it allows you to centralize your response handling logic. If the API team changes a status value, you update the enum in one place, and the compiler highlights all affected assertions across your entire project. This approach transforms brittle, error-prone string comparisons into a robust, type-aware verification system that keeps your test suite aligned with your service's evolving contract.

enum HttpStatus {
  OK = 200,
  UNAUTHORIZED = 401,
  NOT_FOUND = 404
}

// Using enum for safe verification
const response = await request.get('/user/profile');
if (response.status() === HttpStatus.OK) {
  console.log('User data retrieved safely');
}

Type-Safe Assertions with Generics

TypeScript generics empower you to write highly reusable assertions that adapt to different data types while maintaining strict type safety. By defining a generic function to validate API payloads, you can pass in specific interface structures, ensuring that your test checks for the existence of required fields before executing assertions. This prevents the common trap of accessing nested object properties that might be undefined, which leads to runtime crashes during test execution. Generics allow the same validation logic to work for both a 'User' response and an 'Order' response while still providing full IDE feedback about which properties are valid for each type. This creates a powerful layer of defensive testing that keeps your assertions clean and expressive, ensuring that your test code remains as structured and reliable as the source code of the application you are verifying.

async function validatePayload<T>(response: Response): Promise<T> {
  const data = await response.json();
  // Return casted data safely
  return data as T;
}

interface User { id: number; name: string; }
// Usage with a specific type
const user = await validatePayload<User>(apiResponse);

Interview questions

All Playwright interview questions →

Check yourself

Take the full Playwright quiz →