In the world of test automation, especially with a tool as powerful as Playwright, we often face a classic architectural challenge - the BasePage object. It starts small, but soon it grows into a monolithic "God object" containing methods for every shared component across the application (navigation, footers, modals).
This leads to deep and rigid inheritance chains. An ArticlePage might inherit from NavPage, which inherits from BasePage. This is not only complex but also violates the single responsibility principle.
What if we could build our Page Objects with components just like we build modern web apps? This is where the Mixin Design Pattern comes in, favoring flexible composition over rigid inheritance.
What's the Problem with Inheritance?
Traditional inheritance (class A extends B) is powerful, but it has limits. A class can only extend one other class.
So, what happens when your ArticlePage needs navigation and table-handling logic, and your HomePage needs navigation and table logic? You can't extend NavPage, TablePage. This forces you to either cram everything into a single BasePage or create convoluted inheritance chains.
The Mixin Solution: Composition
The Mixin Design Pattern lets you create reusable "feature packs". They are small classes focused on a single piece of functionality (like navigation or table handling). You can then "mix" these feature packs into any Page Object that needs them.
This approach allows you to:
Share functionality across unrelated classes.
Avoid deep inheritance chains, keeping your code flat and manageable.
Keep Page Objects clean and focused on their primary purpose.
In modern front-end development, which is heavily component-based, our testing frameworks should evolve too. By using the Mixin Design Pattern, we can build a more modular, reusable, and maintainable test suite.
🚀 Implementing Mixins in Playwright with TypeScript
Let's walk through a practical example of adding shared navigation functionality to a HomePage object without using inheritance. All examples are made for tha app that I am always using - Conduit (huge shoutouts to mr. Artem Bondar) and there is a complete Repository.
Step 1: The applyMixins Helper Function
TypeScript doesn't have a native mixin keyword. So, first, we need a small utility function that does the heavy lifting. This function copies the properties and methods from our "feature packs" to our target class.
Think of this as the engine of our pattern.
TypeScript
export function applyMixins(derivedCtor: any, constructors: any[]): void {
constructors.forEach((baseCtor) => {
Object.getOwnPropertyNames(baseCtor.prototype).forEach((name) => {
if (name !== 'constructor') {
Object.defineProperty(
derivedCtor.prototype,
name,
Object.getOwnPropertyDescriptor(baseCtor.prototype, name) ||
Object.create(null)
);
}
});
});
}
Step 2: Create the "Feature Pack" - NavPage
Next, we create our mixin. In this case, it's a NavPage class that encapsulates all locators and methods for interacting with the website's main navigation bar, a component present on almost every page.
This class is our reusable piece of code.
TypeScript
import { Page, Locator, expect } from '@playwright/test';
export class NavPage {
constructor(protected page: Page) {}
get signInNavigationLink(): Locator {
return this.page.getByRole('link', { name: 'Sign in' });
}
get emailInput(): Locator {
return this.page.getByRole('textbox', { name: 'Email' });
}
get passwordInput(): Locator {
return this.page.getByRole('textbox', { name: 'Password' });
}
get signInButton(): Locator {
return this.page.getByRole('button', { name: 'Sign in' });
}
async logIn(email: string, password: string): Promise<void> {
await this.navigateToSignInPage();
await this.emailInput.fill(email);
await this.passwordInput.fill(password);
await this.signInButton.click();
await expect(
this.page.getByRole('navigation').getByText(process.env.USER_NAME!)
).toBeVisible();
}
}
Step 3: Compose the HomePage with the NavPage Mixin
Now for the magic. We create our HomePage object, which is responsible only for elements unique to the home page. Then, we use our applyMixins helper to blend in the NavPage functionality.
TypeScript
import { Page, Locator, expect } from '@playwright/test';
import { applyMixins } from '../../helpers/mixin';
import { NavPage } from './baseClasses/navPage';
export class HomePage {
constructor(protected page: Page) {}
get homeBanner(): Locator {
return this.page.getByRole('heading', { name: 'conduit' });
}
get yourFeedBtn(): Locator {
return this.page.getByText('Your Feed');
}
async navigateToHomePageGuest(): Promise<void> {
await this.page.goto(process.env.URL as string);
await expect(this.homeBanner).toBeVisible();
}
}
export interface HomePage extends NavPage {}
applyMixins(HomePage, [NavPage]);
Notice two key parts here:
export interface HomePage extends NavPage {}: This is crucial for TypeScript's type-checking. It tells the compiler, "Trust me, an instance of HomePage will also have all the methods of NavPage", giving us that sweet, sweet IntelliSense autocompletion.
applyMixins(HomePage, [NavPage]): This is the runtime execution. It takes all the methods from NavPage and attaches them to HomePage. If you want to attach methods from more than one baseClass, you can list them in the array.
Step 4: Use the Composed Page Object in a Test
Finally, let's see it in action. In our test file, we can instantiate HomePage and call methods from NavPage directly on it, like logIn().
TypeScript
import { test as setup } from '../fixtures/pom/test-options';
setup('auth user', async ({ homePage, page }) => {
await setup.step('create logged in user session', async () => {
await homePage.navigateToHomePageGuest();
await homePage.logIn(process.env.EMAIL!, process.env.PASSWORD!);
await page.context().storageState({ path: '.auth/userSession.json' });
});
});
It just works! Our HomePage is clean and focused, yet it has all the power of the navigation functionality when needed.
A Note on Potential Downsides
While powerful, this pattern has trade-offs. The main one is the potential for method name collisions. If you mix in two classes that both define a method called clickSubmit(), the last one applied will overwrite the previous ones. Additionally, it can sometimes be less obvious where a method originates compared to a clear extends chain.
Summary
By embracing a composition over inheritance mindset with the Mixin pattern, you can build a far more flexible, modular, and maintainable Playwright test automation framework.
Your Page Objects become cleaner, your code becomes more reusable, and you avoid the architectural headache of the monolithic BasePage. This approach better mirrors modern, component-based web development and leads to a more robust and scalable test suite.
