The Blueprint for Success: Essential Design Patterns for Test Automation Frameworks

 

Building a test automation framework isn't just about writing automated scripts; it's about designing a robust, scalable, and maintainable ecosystem for your tests. Just like architects use blueprints and engineers apply proven principles, automation specialists leverage design patterns – reusable solutions to common software design problems – to construct frameworks that stand the test of time.

In this deep dive, we'll explore some of the most influential and widely adopted design patterns in test automation, explaining their purpose, benefits, and how they contribute to a superior automation experience.

Why Design Patterns in Test Automation?

Without design patterns, test automation code can quickly devolve into a chaotic, unmaintainable mess characterized by:

• Code Duplication (violating DRY): Repeating the same logic across multiple tests.

• Tight Coupling: Changes in one part of the application UI or logic break numerous tests.

• Poor Readability: Difficult to understand what a test is doing or why it's failing.

• Scalability Issues: Hard to add new tests or features without major refactoring.

• High Maintenance Costs: Every small change requires significant updates across the codebase.

Design patterns provide a structured approach to tackle these issues, fostering:

• Maintainability: Easier to update and evolve the framework as the application changes.

• Reusability: Write code once, use it many times.

• Readability: Clearer separation of concerns makes the code easier to understand.

• Scalability: The framework can grow efficiently with the application.

• Flexibility: Adapt to new requirements or technologies with less effort.

Let's explore the key patterns:

1. Page Object Model (POM)

The Page Object Model (POM) is arguably the most fundamental and widely adopted design pattern in UI test automation. It advocates for representing each web page or significant component of your application's UI as a separate class.

• Core Idea: Separate the UI elements (locators) and interactions (methods) of a page from the actual test logic.

• How it Works:

  • For every significant page (e.g., Login Page, Dashboard Page, Product Details Page), create a corresponding "Page Object" class.

  • Inside the Page Object class, define locators for all interactive elements on that page (buttons, input fields, links, etc.).

  • Define methods within the Page Object that encapsulate interactions a user can perform on that page (e.g., login(username, password), addToCart(), verifyProductTitle()). These methods should typically return another Page Object, or nothing if the action keeps the user on the same page.

• Benefits:

  • Maintainability: If a UI element's locator changes, you only need to update it in one place (the Page Object), not across dozens of tests.

  • Readability: Test scripts become more business-readable, focusing on "what" to do (loginPage.login(...)) rather than "how" to do it (finding elements, typing text).

  • Reusability: Page Object methods can be reused across multiple test scenarios.

  • Separation of Concerns: Clearly separates test logic from UI implementation details.

• Example (Conceptual - Playwright):

  TypeScript

  // pages/LoginPage.ts
  import { Page, expect } from '@playwright/test';
  
  export class LoginPage {
    readonly page: Page;
    readonly usernameInput = '#username';
    readonly passwordInput = '#password';
    readonly loginButton = '#login-button';
    readonly errorMessage = '.error-message';
  
    constructor(page: Page) {
      this.page = page;
    }
  
    async navigate() {
      await this.page.goto('/login');
    }
  
    async login(username, password) {
      await this.page.fill(this.usernameInput, username);
      await this.page.fill(this.passwordInput, password);
      await this.page.click(this.loginButton);
    }
  
    async getErrorMessage() {
      return await this.page.textContent(this.errorMessage);
    }
  
    async expectToBeLoggedIn() {
      await expect(this.page).toHaveURL(/dashboard/);
    }
  }
  
  // tests/login.spec.ts
  import { test } from '@playwright/test';
  import { LoginPage } from '../pages/LoginPage';
  import { DashboardPage } from '../pages/DashboardPage'; // Assuming you have one
  
  test('should allow a user to log in successfully', async ({ page }) => {
    const loginPage = new LoginPage(page);
    const dashboardPage = new DashboardPage(page);
  
    await loginPage.navigate();
    await loginPage.login('testuser', 'password123');
    await dashboardPage.expectToBeOnDashboard();
  });
  

2. Factory Pattern

The Factory Pattern provides a way to create objects without exposing the instantiation logic to the client (your test). Instead of directly using new operator to create objects, you delegate object creation to a "factory" method or class.

• Core Idea: Centralize object creation, making it flexible and easy to introduce new object types without modifying existing client code.

• How it Works: A "factory" class or method determines which concrete class to instantiate based on input parameters or configuration, and returns an instance of that class (often via a common interface).

• Benefits:

  • Decoupling: Test code doesn't need to know the specific concrete class it's working with, only the interface.

  • Flexibility: Easily switch between different implementations (e.g., different browsers, different API versions, different test data generators) by changing a single parameter in the factory.

  • Encapsulation: Hides the complexity of object creation logic.

• Common Use Cases in Automation:

  • WebDriver/Browser Factory: Creating ChromeDriver, FirefoxDriver, Playwright Chromium, Firefox, WebKit instances based on a configuration.

  • Test Data Factory: Generating different types of test data objects (e.g., AdminUser, CustomerUser, GuestUser) based on a specified role.

  • API Client Factory: Providing different API client implementations (e.g., RestAPIClient, GraphQLAPIClient).

• Example (Conceptual - Browser Factory):

  TypeScript

  // factories/BrowserFactory.ts
  import { chromium, firefox, webkit, Browser } from '@playwright/test';
  
  type BrowserType = 'chromium' | 'firefox' | 'webkit';
  
  export class BrowserFactory {
    static async getBrowser(type: BrowserType): Promise<Browser> {
      switch (type) {
        case 'chromium':
          return await chromium.launch();
        case 'firefox':
          return await firefox.launch();
        case 'webkit':
          return await webkit.launch();
        default:
          throw new Error(`Unsupported browser type: ${type}`);
      }
    }
  }
  
  // tests/multi-browser.spec.ts
  import { test, Page } from '@playwright/test';
  import { BrowserFactory } from '../factories/BrowserFactory';
  
  // This is more often used with Playwright's `projects` configuration,
  // but demonstrates the factory concept for other contexts like custom WebDriver instances.
  test('should test on chromium via factory', async () => {
    const browser = await BrowserFactory.getBrowser('chromium');
    const page = await browser.newPage();
    await page.goto('https://www.example.com');
    // ... test something
    await browser.close();
  });
  

3. Singleton Pattern

The Singleton Pattern ensures that a class has only one instance and provides a global point of access to that instance.

• Core Idea: Restrict the instantiation of a class to a single object.

• How it Works: A class itself controls its instantiation, typically by having a private constructor and a static method that returns the single instance.

• Benefits:

  • Resource Management: Prevents the creation of multiple, resource-heavy objects (e.g., multiple browser instances, multiple database connections).

  • Global Access: Provides a single, well-known point of access for a shared resource.

• Common Use Cases in Automation:

  • WebDriver/Browser Instance: Ensuring only one instance of the browser is running for a test execution (though Playwright's default page fixture often handles this elegantly per test/worker).

  • Configuration Manager: A single instance to load and provide configuration settings across the framework.

  • Logger: A centralized logging mechanism.

• Example (Conceptual - Configuration Manager):

  TypeScript

  // utils/ConfigManager.ts
  import * as fs from 'fs';
  
  class ConfigManager {
    private static instance: ConfigManager;
    private config: any;
  
    private constructor() {
      // Load configuration from a file or environment variables
      console.log('Loading configuration...');
      const configPath = process.env.CONFIG_PATH || './config.json';
      this.config = JSON.parse(fs.readFileSync(configPath, 'utf-8'));
    }
  
    public static getInstance(): ConfigManager {
      if (!ConfigManager.instance) {
        ConfigManager.instance = new ConfigManager();
      }
      return ConfigManager.instance;
    }
  
    public get(key: string): any {
      return this.config[key];
    }
  }
  
  // tests/example.spec.ts
  import { test, expect } from '@playwright/test';
  import { ConfigManager } from '../utils/ConfigManager';
  
  test('should use base URL from config', async ({ page }) => {
    const config = ConfigManager.getInstance();
    const baseUrl = config.get('baseURL');
    console.log(`Using base URL: ${baseUrl}`);
    await page.goto(baseUrl);
    // ...
  });
  

  Note: While useful, be cautious with Singletons as they can introduce global state, making testing harder. Playwright's fixture system often provides a more flexible alternative for managing shared resources across tests/workers.

4. Builder Pattern

The Builder Pattern is used to construct complex objects step by step. It separates the construction of a complex object from its representation, allowing the same construction process to create different representations.

• Core Idea: Provide a flexible and readable way to create complex objects, especially those with many optional parameters.

• How it Works: Instead of a single, large constructor, a "builder" class provides step-by-step methods to set properties of an object. A final build() method returns the constructed object.

• Benefits:

  • Readability: Clearer than constructors with many parameters.

  • Flexibility: Easily create different variations of an object by chaining methods.

  • Immutability (Optional): Can be used to create immutable objects once build() is called.

• Common Use Cases in Automation:

  • Test Data Creation: Building complex user profiles, product data, or order details with various attributes.

  • API Request Builder: Constructing complex HTTP requests with headers, body, query parameters, etc.

• Example (Conceptual - User Test Data Builder):

  TypeScript

  // builders/UserBuilder.ts
  interface User {
    firstName: string;
    lastName: string;
    email: string;
    role: 'admin' | 'customer' | 'guest';
    isActive: boolean;
  }
  
  export class UserBuilder {
    private user: User;
  
    constructor() {
      // Set default values
      this.user = {
        firstName: 'John',
        lastName: 'Doe',
        email: 'john.doe@example.com',
        role: 'customer',
        isActive: true,
      };
    }
  
    withFirstName(firstName: string): UserBuilder {
      this.user.firstName = firstName;
      return this;
    }
  
    withLastName(lastName: string): UserBuilder {
      this.user.lastName = lastName;
      return this;
    }
  
    asAdmin(): UserBuilder {
      this.user.role = 'admin';
      return this;
    }
  
    asGuest(): UserBuilder {
      this.user.role = 'guest';
      return this;
    }
  
    inactive(): UserBuilder {
      this.user.isActive = false;
      return this;
    }
  
    build(): User {
      return { ...this.user }; // Return a copy to ensure immutability
    }
  }
  
  // tests/user-registration.spec.ts
  import { test, expect } from '@playwright/test';
  import { UserBuilder } from '../builders/UserBuilder';
  import { RegistrationPage } from '../pages/RegistrationPage';
  
  test('should register a new admin user', async ({ page }) => {
    const adminUser = new UserBuilder()
      .withFirstName('Admin')
      .withLastName('User')
      .asAdmin()
      .build();
  
    const registrationPage = new RegistrationPage(page);
    await registrationPage.navigate();
    await registrationPage.registerUser(adminUser);
    await expect(page.locator('.registration-success-message')).toBeVisible();
  });
  
  test('should register an inactive guest user', async ({ page }) => {
    const guestUser = new UserBuilder()
      .withFirstName('Guest')
      .inactive()
      .asGuest()
      .build();
  
    const registrationPage = new RegistrationPage(page);
    await registrationPage.navigate();
    await registrationPage.registerUser(guestUser);
    // ... assert inactive user behavior
  });
  

5. Strategy Pattern

The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. It allows the client (your test) to choose an algorithm at runtime without changing the context object that uses it.

• Core Idea: Decouple the client code from the specific implementation of an algorithm.

• How it Works: You define an interface for a set of related algorithms (strategies). Concrete classes implement this interface, each providing a different algorithm. A "context" object holds a reference to a strategy and delegates the execution to it.

• Benefits:

  • Flexibility: Easily swap different algorithms at runtime.

  • Reduced Conditional Logic: Avoids large if-else or switch statements for different behaviors.
    

  • Open/Closed Principle: New strategies can be added without modifying existing code.

• Common Use Cases in Automation:

  • Login Strategies: Different ways to log in (e.g., standard form, SSO, API login).

  • Data Validation Strategies: Different rules for validating input fields.

  • Reporting Strategies: Generating test reports in different formats (HTML, JSON, XML).

  • Payment Gateway Integration: Testing different payment methods.

• Example (Conceptual - Login Strategy):

  TypeScript
  

  // strategies/ILoginStrategy.ts
  import { Page } from '@playwright/test';
  
  export interface ILoginStrategy {
    login(page: Page, username?: string, password?: string): Promise<void>;
  }
  
  // strategies/FormLoginStrategy.ts
  import { ILoginStrategy } from './ILoginStrategy';
  import { Page } from '@playwright/test';
  
  export class FormLoginStrategy implements ILoginStrategy {
    async login(page: Page, username, password): Promise<void> {
      console.log('Logging in via Form...');
      await page.goto('/login');
      await page.fill('#username', username);
      await page.fill('#password', password);
      await page.click('#login-button');
      await page.waitForURL(/dashboard/);
    }
  }
  
  // strategies/ApiLoginStrategy.ts
  import { ILoginStrategy } from './ILoginStrategy';
  import { Page } from '@playwright/test';
  // Assume an API client for actual API calls
  
  export class ApiLoginStrategy implements ILoginStrategy {
    async login(page: Page, username, password): Promise<void> {
      console.log('Logging in via API (and setting session)...');
      // This would involve making an actual API call to get a session token
      // and then injecting it into the browser context.
      // For demonstration, let's simulate setting a token directly:
      const sessionToken = `mock-token-${username}`; // In real life, get this from API
      await page.goto('/dashboard'); // Go to dashboard first
      await page.evaluate(token => {
        localStorage.setItem('authToken', token);
      }, sessionToken);
      await page.reload(); // Reload page to pick up the token
      await page.waitForURL(/dashboard/);
    }
  }
  
  // context/LoginContext.ts
  import { Page } from '@playwright/test';
  import { ILoginStrategy } from '../strategies/ILoginStrategy';
  
  export class LoginContext {
    private strategy: ILoginStrategy;
    private page: Page;
  
    constructor(page: Page, strategy: ILoginStrategy) {
      this.page = page;
      this.strategy = strategy;
    }
  
    setStrategy(strategy: ILoginStrategy) {
      this.strategy = strategy;
    }
  
    async performLogin(username: string, password?: string): Promise<void> {
      await this.strategy.login(this.page, username, password);
    }
  }
  
  // tests/login-strategies.spec.ts
  import { test, expect } from '@playwright/test';
  import { LoginContext } from '../context/LoginContext';
  import { FormLoginStrategy } from '../strategies/FormLoginStrategy';
  import { ApiLoginStrategy } from '../strategies/ApiLoginStrategy';
  
  test('should login via form successfully', async ({ page }) => {
    const loginContext = new LoginContext(page, new FormLoginStrategy());
    await loginContext.performLogin('formuser', 'formpass');
    await expect(page).toHaveURL(/dashboard/);
    await expect(page.locator('.welcome-message')).toBeVisible();
  });
  
  test('should login via API successfully', async ({ page }) => {
    const loginContext = new LoginContext(page, new ApiLoginStrategy());
    await loginContext.performLogin('apiuser'); // Password might be irrelevant for API login
    await expect(page).toHaveURL(/dashboard/);
    await expect(page.locator('.welcome-message')).toBeVisible();
  });
  

Other Relevant Patterns (Briefly Mentioned):

• Facade Pattern: Provides a simplified interface to a complex subsystem. Useful for simplifying interactions with multiple Page Objects for a complex end-to-end flow.

• Observer Pattern: Useful for handling events, such as logging test results or triggering actions based on UI changes.

• Dependency Injection (DI): A powerful concept often used in conjunction with design patterns to manage dependencies between classes, making your framework more modular and testable. Playwright's fixture system inherently uses a form of DI.

Conclusion: Designing for the Future

Adopting design patterns is a critical step in maturing your test automation framework. They provide a common language for your team, promote best practices, and deliver tangible benefits in terms of maintainability, scalability, and reusability.

Start by implementing the Page Object Model – it's the cornerstone for most UI automation. As your framework grows in complexity, explore how Factory, Singleton, Builder, and Strategy patterns can address specific challenges and elevate your automation to the next level. Remember, the goal isn't to use every pattern, but to choose the right pattern for the right problem, creating a robust blueprint for your automation success.

Happy designing and automating!

Read More

Unlocking Efficiency: A Deep Dive into Playwright Custom Fixtures

 

As automation engineers, we constantly strive for cleaner, more maintainable, and highly efficient test suites. Repetitive setup code, complex beforeEach hooks, and duplicated login logic can quickly turn a promising test framework into a tangled mess. This is where Playwright's custom fixtures shine, offering a powerful and elegant solution to encapsulate setup and teardown logic, share state, and create a truly modular test architecture.

If you're looking to elevate your Playwright test automation, understanding and leveraging custom fixtures is an absolute must. Let's dive in!

What are Playwright Fixtures?

At its core, a Playwright fixture is a way to set up the environment for a test, providing it with everything it needs and nothing more. You've already encountered them: page, browser, context, request, browserName – these are all built-in Playwright fixtures. When you write async ({ page }) => { ... }, you're telling Playwright to "fix up" a page object and provide it to your test.

Why are fixtures superior to traditional beforeEach/afterEach hooks?

• Encapsulation: Setup and teardown logic are kept together in one place, making it easier to understand and maintain.

• Reusability: Define a fixture once, use it across multiple test files. No more copying-pasting common helper functions.

• On-Demand: Playwright only runs fixtures that a test explicitly requests, optimizing execution time.

• Composability: Fixtures can depend on other fixtures, allowing you to build complex test environments incrementally.

• Isolation: Each test gets a fresh, isolated environment (by default), preventing test interdependencies and flakiness.

Creating Your First Custom Fixture: The loggedInPage Example

Let's imagine a common scenario: many of your tests require a user to be logged into the application. Repeating the login steps in every test is inefficient and brittle. This is a perfect use case for a custom fixture.

First, let's create a dedicated file for our custom fixtures, conventionally named fixtures/my-fixtures.ts (or .js):

fixtures/my-fixtures.ts

TypeScript

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

// Declare the types of your fixtures.
// This provides type safety and autocompletion for your custom fixture.
type MyFixtures = {
  loggedInPage: Page; // Our custom fixture will provide a Playwright Page object
};

// Extend the base Playwright test object.
// The first generic parameter {} is for worker-scoped fixtures (we'll cover this later).
// The second generic parameter MyFixtures declares our test-scoped fixtures.
export const test = base.extend<MyFixtures>({
  // Define our custom 'loggedInPage' fixture
  loggedInPage: async ({ page }, use) => {
    // --- Setup Logic (runs BEFORE the test) ---
    console.log('--- Setting up loggedInPage fixture ---');

    // Perform login steps
    await page.goto('https://www.example.com/login'); // Replace with your login URL
    await page.fill('#username', 'testuser');
    await page.fill('#password', 'Test@123');
    await page.click('#login-button');

    // You might add an assertion here to ensure login was successful
    await page.waitForURL('**/dashboard'); // Wait for the dashboard page after login

    // Use the fixture value in the test.
    // Whatever value you pass to 'use()' will be available to the test.
    await use(page);

    // --- Teardown Logic (runs AFTER the test) ---
    console.log('--- Tearing down loggedInPage fixture ---');
    // For a 'page' fixture, usually Playwright handles closing the page/context.
    // But if you opened a new browser context or created temporary data, you'd clean it up here.
    // Example: logging out (though often not strictly necessary for test isolation with fresh contexts)
    // await page.click('#logout-button');
  },
});

// Re-export Playwright's expect for convenience when using this custom test object
export { expect } from '@playwright/test';

Now, instead of importing test from @playwright/test in your spec files, you'll import it from your custom fixture file:

tests/dashboard.spec.ts

TypeScript

import { test, expect } from '../fixtures/my-fixtures'; // Import your extended test

test('should display dashboard content after login', async ({ loggedInPage }) => {
  // 'loggedInPage' is already logged in, thanks to our fixture!
  await expect(loggedInPage.locator('.welcome-message')).toHaveText('Welcome, testuser!');
  await expect(loggedInPage.locator('nav.dashboard-menu')).toBeVisible();
});

test('should navigate to settings from logged-in page', async ({ loggedInPage }) => {
  await loggedInPage.click('a[href="/settings"]');
  await expect(loggedInPage).toHaveURL('**/settings');
  await expect(loggedInPage.locator('h1')).toHaveText('User Settings');
});

// You can still use built-in fixtures alongside your custom ones
test('should work with a fresh page without login', async ({ page }) => {
  await page.goto('https://www.example.com/public-page');
  await expect(page.locator('h1')).toHaveText('Public Information');
});

When you run npx playwright test, Playwright will:

1. See that dashboard.spec.ts imports test from my-fixtures.ts.

2. For the first test, it sees loggedInPage requested. It executes the loggedInPage fixture's setup logic (login steps).

3. It then runs the test, providing the page object that was logged in.

4. After the test, it executes the loggedInPage fixture's teardown logic (if any).

5. For the third test, it sees page requested. It uses Playwright's default page fixture setup.

Advanced Fixture Concepts

1. Fixture Scopes: test vs. worker

Fixtures can have different scopes, dictating how often their setup and teardown logic runs:

• 'test' (Default): The fixture is set up before each test that uses it and torn down after that test finishes. This ensures complete isolation between tests. Ideal for state specific to one test (e.g., a specific page instance, a unique temporary user account).

• 'worker': The fixture is set up once per worker process (Playwright runs tests in parallel using workers) before any tests in that worker run, and torn down after all tests in that worker have completed. Ideal for expensive resources that can be shared across multiple tests (e.g., a database connection pool, an API client, a mock server).

Example: Worker-Scoped apiClient Fixture

Let's create a worker-scoped fixture for an API client, useful if many tests interact with the same API.

fixtures/my-fixtures.ts (updated)

TypeScript

import { test as base, Page } from '@playwright/test';
import { APIClient } from './api-client'; // Assuming you have an APIClient class

// Declare types for both test-scoped and worker-scoped fixtures
type MyTestFixtures = {
  loggedInPage: Page;
};

type MyWorkerFixtures = {
  apiClient: APIClient;
};

export const test = base.extend<MyTestFixtures, MyWorkerFixtures>({
  // Worker-scoped fixture for API client
  apiClient: [async ({}, use) => {
    // --- Setup Logic (runs ONCE per worker) ---
    console.log('--- Setting up apiClient (worker scope) ---');
    const client = new APIClient('https://api.example.com'); // Initialize your API client
    await client.authenticate('admin', 'secret'); // Or perform global API setup

    await use(client); // Provide the authenticated API client to tests

    // --- Teardown Logic (runs ONCE per worker after all tests) ---
    console.log('--- Tearing down apiClient (worker scope) ---');
    // Disconnect API client, clean up global resources
    await client.disconnect();
  }, { scope: 'worker' }], // Specify the 'worker' scope here

  // Your existing test-scoped loggedInPage fixture
  loggedInPage: async ({ page, apiClient }, use) => { // loggedInPage can depend on apiClient!
    console.log('--- Setting up loggedInPage fixture ---');

    // Example of using apiClient from within loggedInPage fixture
    const userCredentials = await apiClient.getUserCredentials('testuser');
    await page.goto('https://www.example.com/login');
    await page.fill('#username', userCredentials.username);
    await page.fill('#password', userCredentials.password);
    await page.click('#login-button');
    await page.waitForURL('**/dashboard');

    await use(page);
    console.log('--- Tearing down loggedInPage fixture ---');
  },
});

export { expect } from '@playwright/test';

Now, your apiClient will only be initialized and torn down once per worker, saving significant time if you have many API-dependent tests.

2. Auto-Fixtures (auto: true)

Sometimes you want a fixture to run for every test that uses your extended test object, without explicitly declaring it in each test function. This is where auto: true comes in handy.

Use cases for auto: true:

• Global logging setup/teardown.

• Starting/stopping a mock server for all tests.

• Ensuring a clean state (e.g., clearing browser storage) before every test.

Example: Clearing Local Storage Automatically

fixtures/my-fixtures.ts (updated)

TypeScript

import { test as base, Page } from '@playwright/test';
// ... (MyTestFixtures, MyWorkerFixtures types and apiClient fixture from above)

export const test = base.extend<MyTestFixtures, MyWorkerFixtures>({
  // ... (apiClient and loggedInPage fixtures)

  // Auto-fixture to clear local storage before each test
  clearLocalStorage: [async ({ page }, use) => {
    console.log('Clearing local storage before test...');
    await page.evaluate(() => localStorage.clear());
    await use(); // The 'use' function is called without a value if the fixture itself doesn't provide one.
    console.log('Local storage clean up complete.');
  }, { auto: true }], // This fixture will run automatically for all tests
});

export { expect } from '@playwright/test';

Now, every test that imports test from my-fixtures.ts will automatically have its local storage cleared before execution, ensuring a clean state.

3. Overriding Built-in and Custom Fixtures

Playwright allows you to override existing fixtures, including built-in ones. This is incredibly powerful for customising behavior.

Example: Overriding page to Automatically Navigate to baseURL

You might want every page instance to automatically navigate to your baseURL defined in playwright.config.ts.

fixtures/my-fixtures.ts (updated)

TypeScript

import { test as base, Page } from '@playwright/test';
// ... (MyTestFixtures, MyWorkerFixtures types)

export const test = base.extend<MyTestFixtures, MyWorkerFixtures>({
  // Override the built-in 'page' fixture
  page: async ({ page, baseURL }, use) => {
    if (baseURL) {
      await page.goto(baseURL); // Automatically go to baseURL
    }
    await use(page); // Pass the configured page to the test
  },
  // ... (Other custom fixtures like loggedInPage, apiClient, clearLocalStorage)
});

export { expect } from '@playwright/test';

Now, in any test that uses { page }, it will automatically navigate to your baseURL before the test code executes, reducing boilerplate.

4. Parameterizing Fixtures with Option Fixtures

Sometimes, you need to configure a fixture based on specific test requirements or global settings. Playwright provides "option fixtures" for this.

Example: user Fixture with Configurable role

Let's create a user fixture that provides user data, and we want to configure the user's role.

fixtures/my-fixtures.ts (updated)

TypeScript

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

type UserRole = 'admin' | 'editor' | 'viewer';

type MyTestFixtures = {
  // Our new custom user fixture
  user: { name: string; email: string; role: UserRole; };
  loggedInPage: Page;
};

type MyWorkerFixtures = {
  apiClient: APIClient;
};

// Define an "option fixture" for the user role
// The value of this option can be overridden in playwright.config.ts or per test file
type MyOptionFixtures = {
  userRole: UserRole;
};

export const test = base.extend<MyTestFixtures, MyWorkerFixtures, MyOptionFixtures>({
  // Define the option fixture with a default value
  userRole: ['viewer', { option: true }],

  // The 'user' fixture depends on the 'userRole' option fixture
  user: async ({ userRole }, use) => {
    let userData: { name: string; email: string; role: UserRole; };
    switch (userRole) {
      case 'admin':
        userData = { name: 'Admin User', email: 'admin@example.com', role: 'admin' };
        break;
      case 'editor':
        userData = { name: 'Editor User', email: 'editor@example.com', role: 'editor' };
        break;
      case 'viewer':
      default:
        userData = { name: 'Viewer User', email: 'viewer@example.com', role: 'viewer' };
        break;
    }
    await use(userData);
  },

  // ... (Other custom fixtures like loggedInPage, apiClient, clearLocalStorage)
  // Ensure loggedInPage now uses the 'user' fixture for credentials
  loggedInPage: async ({ page, apiClient, user }, use) => {
    console.log(`--- Setting up loggedInPage for ${user.role} user ---`);
    // Example: You might use user.email and user.password (if stored in user fixture) for login
    // Or simulate API login with apiClient based on user.role
    await page.goto('https://www.example.com/login');
    await page.fill('#username', user.email); // Assuming email is username
    await page.fill('#password', 'shared-password'); // Or get from user fixture
    await page.click('#login-button');
    await page.waitForURL('**/dashboard');

    await use(page);
    console.log('--- Tearing down loggedInPage fixture ---');
  },
});

export { expect } from '@playwright/test';

Now, in your tests, you can easily switch user roles:

tests/user-roles.spec.ts

TypeScript

import { test, expect } from '../fixtures/my-fixtures';

// This test will use the default 'viewer' role
test('viewer user should see dashboard with limited options', async ({ loggedInPage, user }) => {
  expect(user.role).toBe('viewer');
  await expect(loggedInPage.locator('.admin-panel')).not.toBeVisible();
});

// This test will override the 'userRole' option to 'admin'
test.describe('Admin user tests', () => {
  // Override the userRole for all tests in this describe block
  test.use({ userRole: 'admin' });

  test('admin user should see admin panel', async ({ loggedInPage, user }) => {
    expect(user.role).toBe('admin');
    await expect(loggedInPage.locator('.admin-panel')).toBeVisible();
  });

  test('admin user can create new items', async ({ loggedInPage }) => {
    await loggedInPage.click('button.create-new-item');
    // ... test item creation
  });
});

// You can also override the option in playwright.config.ts for entire projects:
// In playwright.config.ts:
// projects: [
//   {
//     name: 'admin-tests',
//     use: { userRole: 'admin' },
//   },
//   {
//     name: 'viewer-tests',
//     use: { userRole: 'viewer' },
//   },
// ]

Best Practices for Custom Fixtures

• DRY (Don't Repeat Yourself): If you find yourself writing the same setup code more than twice, consider a fixture.

• Single Responsibility: Each fixture should ideally have one clear purpose.

• Type Safety: Always declare the types for your custom fixtures using TypeScript to benefit from autocompletion and error checking.

• Granularity: Create smaller, focused fixtures that can be composed, rather than one giant "god" fixture.

• Dependency Management: Leverage fixture dependencies effectively. If FixtureB needs FixtureA, simply include FixtureA in FixtureB's parameters.

• Clear Naming: Give your fixtures descriptive names.

• Scope Wisely: Choose test or worker scope based on whether the resource needs to be isolated per test or shared across tests in a worker.

• Prioritize Teardown: Ensure your teardown logic is robust, especially for external resources (e.g., database connections, temporary files).

• Version Control: Store your custom fixture files in a well-organized directory (e.g., fixtures/) within your test project.

Conclusion

Playwright custom fixtures are more than just a way to manage setup and teardown; they are a fundamental building block for a scalable, maintainable, and readable test automation framework. By mastering their use, you can:

• Reduce boilerplate code and improve test readability.

• Enhance test isolation and reduce flakiness.

• Optimize test execution speed by sharing expensive resources.

• Empower your team to write more effective and consistent tests.

Start by identifying repetitive setup tasks in your existing test suite and gradually refactor them into custom fixtures. You'll quickly see the immense value they bring to your Playwright automation journey.

Happy coding and even happier testing!

Read More