5 Anti-Patterns Teams Carry From Selenium to Playwright (And How to Unlearn Them)

Introduction: Why Your Selenium Habits Are Sabotaging Your Playwright Tests

Migrating from Selenium to Playwright is one of the smartest moves a QA team can make in 2026. Playwright offers modern auto-waiting, built-in parallel execution, superior debugging tools, and a developer experience that makes Selenium feel like a relic from another era. But here is the uncomfortable truth that nobody tells you during the migration: the hardest part is not learning Playwright. It is unlearning Selenium.

🎭 Want to master this with real projects? Join the Playwright Automation Mastery course at The Testing Academy.

After helping dozens of teams migrate their test automation frameworks, I have seen the same five anti-patterns surface again and again. Teams port their Selenium code line by line, preserving every bad habit, every workaround, every architectural compromise they built over years. The result is a Playwright framework that runs like Selenium with extra steps, missing out on the very features that make Playwright transformative.

In this comprehensive guide, I will walk you through the five most dangerous anti-patterns teams carry from Selenium to Playwright, explain why each one is harmful, and show you the modern Playwright-native approach with real before-and-after code examples. Whether you are mid-migration or planning one, this post will save your team weeks of refactoring pain.

Anti-Pattern 1: Using waitForTimeout as a Thread.sleep Replacement

The Selenium Habit

In Selenium, Thread.sleep() was the go-to escape hatch when tests became flaky. Element not loading fast enough? Add a sleep. AJAX call taking too long? Throw in a 5-second wait. Over time, teams accumulated hundreds of these hardcoded waits scattered throughout their test suites, each one adding seconds of unnecessary execution time and masking real synchronization issues.

The typical Selenium pattern looked like this: execute an action, wait a fixed number of milliseconds, then check the result. Even teams that used WebDriverWait often fell back to Thread.sleep for reliability. The cultural dependency on explicit waits ran deep, and it was reinforced every time a sleep fixed a flaky test in the short term while creating a maintenance burden in the long term.

The Selenium Code (Java) – Before

// Selenium Java - The anti-pattern
public class LoginPage {
    private WebDriver driver;

    public void login(String username, String password) {
        driver.findElement(By.id("username")).sendKeys(username);
        driver.findElement(By.id("password")).sendKeys(password);
        driver.findElement(By.id("login-btn")).click();

        // BAD: Hardcoded sleep to wait for dashboard
        Thread.sleep(5000);

        // BAD: Another sleep just to be safe
        Thread.sleep(2000);

        // Now check if login was successful
        Assert.assertTrue(driver.findElement(By.id("dashboard")).isDisplayed());
    }

    public void waitForElement(By locator) {
        // BAD: Polling loop with sleep
        for (int i = 0; i < 10; i++) {
            try {
                if (driver.findElement(locator).isDisplayed()) return;
            } catch (Exception e) {
                Thread.sleep(1000);
            }
        }
    }
}

Why This Is Harmful in Playwright

When teams migrate, they discover page.waitForTimeout() in Playwright and immediately reach for it as a drop-in replacement for Thread.sleep. The migration diff looks clean: replace Thread.sleep(5000) with await page.waitForTimeout(5000). But this completely defeats the purpose of Playwright auto-wait mechanism.

Playwright was designed from the ground up with actionability checks. Every action like click, fill, or check automatically waits for the element to be visible, stable, enabled, and receiving events. When you add waitForTimeout, you are telling Playwright to ignore its smart waiting. The auto-wait mechanism handles timing variations across machines, CI environments, and network conditions far more reliably than any hardcoded delay ever could.

Furthermore, waitForTimeout adds a fixed delay whether the application is ready in 200ms or 4900ms. On fast machines, you waste time. On slow CI runners, 5 seconds might not be enough anyway. It is a lose-lose pattern that creates the exact flakiness it was meant to prevent. Every waitForTimeout in your codebase is a ticking time bomb waiting to cause a false failure or hide a real bug.

The Playwright Fix (TypeScript) – After

// Playwright TypeScript - The correct approach
import { test, expect } from '@playwright/test';

test('user can log in successfully', async ({ page }) => {
  await page.goto('/login');

  // Auto-waits for elements to be actionable
  await page.getByLabel('Username').fill('testuser');
  await page.getByLabel('Password').fill('securepass');
  await page.getByRole('button', { name: 'Log in' }).click();

  // GOOD: Assert the expected state - Playwright auto-waits
  await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();

  // GOOD: Assert specific content if needed
  await expect(page.getByText('Welcome back, testuser')).toBeVisible();

  // GOOD: Wait for specific network response when needed
  const responsePromise = page.waitForResponse('**/api/user/profile');
  await page.getByRole('link', { name: 'Profile' }).click();
  const response = await responsePromise;
  expect(response.status()).toBe(200);
});

Key Takeaway

Replace every waitForTimeout with a meaningful assertion. If you are waiting for an element, use await expect(locator).toBeVisible(). If you are waiting for data, use await expect(locator).toHaveText(). If you need a network response, use page.waitForResponse(). There is always a better alternative than a fixed delay. If you find yourself unable to eliminate a waitForTimeout, that is a sign that your application has a testability problem that should be addressed at the source.

Anti-Pattern 2: Building God Page Objects With 500+ Lines

The Selenium Habit

The Page Object Model was the single most important design pattern in Selenium test automation. It provided a clean separation between test logic and page interactions. But over time, Page Objects grew into monsters. A single HomePage.java might contain 500, 800, or even 1200 lines of code, with methods for every possible interaction on the page: login, search, navigation, footer links, popups, cookie banners, chat widgets, and more.

These God Page Objects became the most dreaded files in the codebase. Nobody wanted to touch them. Merge conflicts were constant. Finding the right method required scrolling through hundreds of lines. And worst of all, they created tight coupling between tests and a monolithic abstraction that did not reflect how the application was actually structured as components.

The Selenium Code (Java) – Before

// Selenium Java - God Page Object anti-pattern
public class HomePage extends BasePage {
    // 50+ locators at the top
    private By searchBox = By.id("search");
    private By searchBtn = By.id("search-btn");
    private By loginLink = By.cssSelector(".login-link");
    private By cartIcon = By.id("cart-icon");
    private By cartCount = By.className("cart-count");
    private By navMenu = By.id("main-nav");
    private By footerLinks = By.cssSelector(".footer a");
    private By cookieBanner = By.id("cookie-consent");
    private By chatWidget = By.id("chat-widget");
    // ... 40 more locators

    // 80+ methods covering everything
    public void searchForProduct(String query) { /* ... */ }
    public void clickSearchResult(int index) { /* ... */ }
    public void login(String user, String pass) { /* ... */ }
    public void logout() { /* ... */ }
    public void addToCart(String productId) { /* ... */ }
    public void removeFromCart(String productId) { /* ... */ }
    public int getCartCount() { /* ... */ }
    public void openChat() { /* ... */ }
    public void acceptCookies() { /* ... */ }
    public List<String> getFooterLinks() { /* ... */ }
    public void navigateToCategory(String cat) { /* ... */ }
    public void sortProducts(String sortBy) { /* ... */ }
    public void filterByPrice(int min, int max) { /* ... */ }
    // ... 65 more methods, 500+ lines total
}

Why This Is Harmful in Playwright

Playwright applications are built with modern component-based frameworks like React, Vue, and Angular. The UI is composed of discrete, reusable components: a search bar, a navigation menu, a shopping cart widget, a chat component. Your test abstractions should mirror this architecture. When you carry over a God Page Object, you are mapping a component-based UI to a monolithic test abstraction. The mismatch creates friction everywhere.

Large Page Objects also make it impossible to leverage Playwright fixtures effectively. You cannot easily scope setup and teardown to individual components. You cannot share a navigation component across multiple page objects without creating complex inheritance hierarchies. And you certainly cannot write focused, fast tests when every interaction requires instantiating a 500-line class that handles every possible interaction on the page.

The Playwright Fix (TypeScript) – After

// Playwright TypeScript - Component-based architecture

// components/SearchBar.ts
export class SearchBar {
  constructor(private page: Page) {}

  private searchInput = () => this.page.getByRole('searchbox');
  private searchButton = () => this.page.getByRole('button', { name: 'Search' });
  private resultItems = () => this.page.getByTestId('search-result');

  async search(query: string) {
    await this.searchInput().fill(query);
    await this.searchButton().click();
  }

  async getResultCount() {
    return await this.resultItems().count();
  }
}

// components/ShoppingCart.ts
export class ShoppingCart {
  constructor(private page: Page) {}

  private cartIcon = () => this.page.getByRole('button', { name: 'Cart' });
  private cartBadge = () => this.page.getByTestId('cart-count');

  async getItemCount() {
    return parseInt(await this.cartBadge().textContent() || '0');
  }

  async open() {
    await this.cartIcon().click();
  }
}

// pages/HomePage.ts - Thin orchestration layer
export class HomePage {
  readonly search: SearchBar;
  readonly cart: ShoppingCart;

  constructor(private page: Page) {
    this.search = new SearchBar(page);
    this.cart = new ShoppingCart(page);
  }

  async goto() {
    await this.page.goto('/');
  }
}

Key Takeaway

Decompose God Page Objects into component classes that mirror your application UI architecture. Each component should be under 100 lines and responsible for a single UI area. The Page Object itself becomes a thin orchestration layer that composes components. This gives you reusability (the SearchBar component works on any page that has a search bar), maintainability (changes to the cart only touch the ShoppingCart class), and clarity (tests read as component interactions).

Anti-Pattern 3: XPath-First Locator Strategy

The Selenium Habit

In the Selenium world, XPath was king. When IDs were missing, CSS selectors were unreliable, and the DOM was a generated mess of random class names, XPath provided a way to reach any element through the DOM tree. Teams developed muscle memory for writing expressions like //div[@class='container']/ul/li[3]/a. Some teams even built XPath helper utilities and maintained XPath libraries that became core dependencies.

The problem was never that XPath did not work. It worked too well. It could locate anything, which meant teams never had to think about whether their locators were resilient, semantic, or aligned with how users actually interact with the page. XPath encouraged a structural approach to element identification that was inherently fragile because it depended on DOM hierarchy rather than user-visible characteristics.

The Selenium Code (Java) – Before

// Selenium Java - XPath-first locator strategy
public class ProductPage {
    private By productTitle = By.xpath("//div[@class='product-detail']/h1");
    private By addToCartBtn = By.xpath("//div[@class='product-actions']//button[contains(@class, 'add-cart')]");
    private By priceLabel = By.xpath("//div[@class='pricing-section']/span[@class='current-price']");
    private By reviewStars = By.xpath("//div[@class='reviews']//div[@class='stars']/span[@class='filled']");
    private By sizeDropdown = By.xpath("//select[@id='size-select']/..//div[@class='custom-dropdown']");
    private By quantityInput = By.xpath("//div[contains(@class, 'quantity')]//input[@type='number']");
    private By firstReview = By.xpath("(//div[@class='review-card'])[1]//p[@class='review-text']");
}

Why This Is Harmful in Playwright

Playwright was designed around a semantic-first locator philosophy. The getByRole(), getByLabel(), getByText(), and getByPlaceholder() locators find elements the same way a user would: by their visible text, their accessible role, or their label. These locators are inherently resilient because they are based on user-facing attributes that are less likely to change than DOM structure or CSS classes.

When teams bring their XPath habits to Playwright, they bypass the entire locator philosophy. They write page.locator("xpath=//div[@class='product']/h1") instead of page.getByRole('heading', { name: 'Product Name' }). The result is tests that are just as brittle as they were in Selenium, but now running in a faster engine. You get speed without resilience.

The Playwright Fix (TypeScript) – After

// Playwright TypeScript - Semantic-first locator strategy
export class ProductPage {
  constructor(private page: Page) {}

  productTitle = () => this.page.getByRole('heading', { level: 1 });
  addToCartButton = () => this.page.getByRole('button', { name: 'Add to cart' });
  currentPrice = () => this.page.getByTestId('current-price');
  sizeSelector = () => this.page.getByLabel('Size');
  quantityInput = () => this.page.getByLabel('Quantity');

  reviewText = (index: number) =>
    this.page.getByTestId('review-card').nth(index).getByTestId('review-text');

  async addToCart(size: string, quantity: number) {
    await this.sizeSelector().selectOption(size);
    await this.quantityInput().fill(String(quantity));
    await this.addToCartButton().click();
    await expect(this.page.getByText('Added to cart')).toBeVisible();
  }
}

Locator Priority Guide

Priority	Locator Type	Example	When to Use
1 (Best)	getByRole	getByRole(‘button’, { name: ‘Submit’ })	Always try first for interactive elements
2	getByLabel	getByLabel(‘Email address’)	Form inputs with associated labels
3	getByPlaceholder	getByPlaceholder(‘Enter email’)	Inputs without visible labels
4	getByText	getByText(‘Welcome back’)	Static content and messages
5	getByTestId	getByTestId(‘product-card’)	When semantic locators are not possible
6 (Last)	CSS / XPath	locator(‘.legacy-widget > div’)	Only for legacy apps with no semantic HTML

Anti-Pattern 4: Inheritance-Heavy Base Classes

The Selenium Habit

In Selenium, the BasePage class was the foundation of every test framework. It contained driver initialization, common utilities, screenshot methods, logging, wait helpers, and cleanup logic. Every Page Object inherited from BasePage, and every test class inherited from BaseTest. Some frameworks had three or four levels of inheritance: BaseTest extends AbstractTest extends TestRunner extends SeleniumCore.

This pattern emerged because Selenium had no built-in mechanism for setup, teardown, or resource management. Teams had to build their own infrastructure for browser lifecycle management, configuration, and cross-cutting concerns. Inheritance was the natural tool for sharing this infrastructure across tests, even though it created rigid hierarchies that were difficult to modify or extend.

The Selenium Code (Java) – Before

// Selenium Java - Inheritance-heavy architecture
public abstract class SeleniumCore {
    protected static WebDriver driver;
    protected static WebDriverWait wait;

    @BeforeAll
    static void setupDriver() {
        System.setProperty("webdriver.chrome.driver", "/path/to/chromedriver");
        ChromeOptions options = new ChromeOptions();
        options.addArguments("--headless");
        driver = new ChromeDriver(options);
        wait = new WebDriverWait(driver, Duration.ofSeconds(10));
    }

    @AfterAll
    static void teardown() {
        if (driver != null) driver.quit();
    }
}

public abstract class BaseTest extends SeleniumCore {
    @BeforeEach
    void beforeEach() {
        driver.manage().deleteAllCookies();
        driver.get(Config.BASE_URL);
    }
    protected void takeScreenshot(String name) { /* ... */ }
}

public abstract class AuthenticatedTest extends BaseTest {
    @BeforeEach
    void login() {
        new LoginPage(driver).login("admin", "admin123");
    }
}

// Every test needs 3 levels of inheritance
public class ProductSearchTest extends AuthenticatedTest {
    @Test
    void shouldSearchProducts() { /* ... */ }
}

Why This Is Harmful in Playwright

Playwright has a first-class fixture system inspired by pytest. Fixtures handle setup, teardown, and resource sharing through composition rather than inheritance. When you bring inheritance hierarchies to Playwright, you are fighting the framework instead of leveraging it. Playwright already manages the browser, context, and page lifecycle. It already provides hooks for screenshots on failure. It already handles parallel execution with isolated contexts.

Deep inheritance creates rigid test hierarchies that are hard to modify, hard to understand, and hard to compose. Need an authenticated test that also has a specific viewport? With inheritance, you need a new class. With fixtures, you just combine them. Fixtures are more flexible, more explicit, and more aligned with how Playwright works internally.

The Playwright Fix (TypeScript) – After

// Playwright TypeScript - Fixtures and composition
import { test as base, expect } from '@playwright/test';

type AuthFixtures = {
  authenticatedPage: Page;
  adminPage: Page;
};

export const test = base.extend<AuthFixtures>({
  authenticatedPage: async ({ page }, use) => {
    await page.goto('/login');
    await page.getByLabel('Username').fill('testuser');
    await page.getByLabel('Password').fill('password');
    await page.getByRole('button', { name: 'Log in' }).click();
    await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
    await use(page);
  },

  adminPage: async ({ browser }, use) => {
    const context = await browser.newContext({
      storageState: 'admin-auth.json',
    });
    const page = await context.newPage();
    await use(page);
    await context.close();
  },
});

// tests/product-search.spec.ts
import { test } from '../fixtures/auth.fixture';

test('authenticated user can search products', async ({ authenticatedPage }) => {
  const page = authenticatedPage;
  await page.getByRole('searchbox').fill('laptop');
  await page.getByRole('button', { name: 'Search' }).click();
  await expect(page.getByTestId('search-results')).toContainText('laptop');
});

Key Takeaway

Replace inheritance hierarchies with Playwright fixtures. Fixtures provide the same functionality (setup, teardown, resource sharing) but through composition rather than inheritance. You can combine any number of fixtures in a single test without creating new classes. Each fixture is self-contained, reusable, and independently testable. The shift from inheritance to composition is perhaps the most architecturally significant change in your migration.

Anti-Pattern 5: Manual Driver and Browser Management

The Selenium Habit

In Selenium, managing the browser lifecycle was a significant engineering challenge. Teams had to download browser drivers, match driver versions to browser versions, configure driver paths, handle driver binaries across operating systems, manage browser options, implement retry logic for browser crashes, and build cleanup routines to kill orphaned browser processes. Entire utility classes were dedicated to this overhead.

Many teams built elaborate DriverFactory patterns with configuration files specifying browser types, headless modes, grid URLs, and capability matrices. Some teams spent more time maintaining their driver management infrastructure than writing actual tests. WebDriverManager libraries emerged specifically to solve the version-matching problem, adding yet another dependency to the stack.

The Selenium Code (Java) – Before

// Selenium Java - Manual driver management
public class DriverFactory {
    private static ThreadLocal<WebDriver> driverThread = new ThreadLocal<>();

    public static WebDriver getDriver() {
        if (driverThread.get() == null) {
            String browser = System.getProperty("browser", "chrome");
            WebDriver driver;
            switch (browser.toLowerCase()) {
                case "chrome":
                    WebDriverManager.chromedriver().setup();
                    ChromeOptions chromeOpts = new ChromeOptions();
                    chromeOpts.addArguments("--headless");
                    chromeOpts.addArguments("--no-sandbox");
                    chromeOpts.addArguments("--window-size=1920,1080");
                    driver = new ChromeDriver(chromeOpts);
                    break;
                case "firefox":
                    WebDriverManager.firefoxdriver().setup();
                    FirefoxOptions ffOpts = new FirefoxOptions();
                    ffOpts.addArguments("--headless");
                    driver = new FirefoxDriver(ffOpts);
                    break;
                default:
                    throw new RuntimeException("Unsupported: " + browser);
            }
            driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));
            driverThread.set(driver);
        }
        return driverThread.get();
    }

    public static void quitDriver() {
        WebDriver driver = driverThread.get();
        if (driver != null) {
            try { driver.quit(); } catch (Exception e) { }
            driverThread.remove();
        }
    }
}

The Playwright Fix (TypeScript) – After

// playwright.config.ts - All configuration in one place
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 4 : undefined,
  use: {
    baseURL: 'https://staging.example.com',
    trace: 'retain-on-failure',
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
  },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    { name: 'mobile-chrome', use: { ...devices['Pixel 7'] } },
    { name: 'mobile-safari', use: { ...devices['iPhone 14'] } },
  ],
});
// No DriverFactory. No driver downloads. No version matching.
// Playwright handles everything.

Key Takeaway

Delete your DriverFactory. Delete your browser management utilities. Delete your driver download scripts. Playwright bundles its own browsers, manages their lifecycle, provides context isolation for parallel execution, and handles all configuration through a single config file. Every line of browser management code you carry over is dead weight that adds complexity without value.

Migration Smell Checklist

Use this checklist to audit your migrated Playwright codebase. Each smell indicates that a Selenium anti-pattern has survived the migration and should be refactored.

Smell	What to Look For	Playwright-Native Fix	Priority
Hardcoded waits	Any call to page.waitForTimeout()	Replace with expect assertions or waitForResponse	Critical
God Page Objects	Any Page Object class over 200 lines	Decompose into component classes	High
XPath locators	Any use of xpath= or page.locator with XPath	Replace with getByRole, getByLabel, getByText	High
Deep inheritance	More than one level of test class inheritance	Convert to Playwright fixtures	High
DriverFactory class	Any manual browser or driver management code	Use playwright.config.ts projects	Medium
ThreadLocal patterns	Thread-based isolation for parallel tests	Use Playwright built-in context isolation	Medium
Retry loops in tests	Custom retry logic wrapping assertions	Use Playwright built-in retries and auto-wait	Medium
Screenshot utilities	Custom screenshot-on-failure code	Use trace: retain-on-failure in config	Low
Config property files	Multiple .properties or .xml config files	Consolidate into playwright.config.ts	Low
Explicit waits wrapper	Custom wait utility classes	Remove entirely – auto-wait handles it	Critical

The Migration Mindset Shift

The five anti-patterns above are symptoms of a deeper issue: treating Playwright as Selenium but faster. It is not. Playwright represents a fundamentally different philosophy of test automation. Selenium was built in an era when the browser was a black box that you controlled through a wire protocol. Playwright was built in an era when the browser is a collaborative partner that you orchestrate through a modern protocol with deep integration.

The mindset shift required is from controlling a browser to collaborating with a framework. Stop managing what Playwright manages for you. Stop building infrastructure that Playwright provides out of the box. Stop writing defensive code for problems that Playwright has already solved. When you trust the framework and write idiomatic Playwright code, you will find that your tests are shorter, faster, more reliable, and more maintainable.

Step-by-Step Migration Action Plan

If you are currently in the middle of a Selenium-to-Playwright migration, here is a practical action plan you can follow immediately:

1. Audit your codebase using the Migration Smell Checklist above. Count the instances of each smell and prioritize the critical ones.
2. Eliminate all waitForTimeout calls first. This gives you the biggest reliability improvement for the least effort.
3. Convert XPath locators to semantic locators one page at a time. Start with your most-run test files and work outward.
4. Decompose God Page Objects by extracting component classes. Start with the largest Page Object and break it into logical components.
5. Replace inheritance with fixtures. Create fixtures for common setup patterns and remove base classes one by one.
6. Delete all browser management code and consolidate configuration into playwright.config.ts.
7. Review and iterate. Run your refactored tests, measure the improvement in reliability and speed.

Conclusion: Unlearn to Excel

The journey from Selenium to Playwright is not just a technical migration. It is a professional evolution. The five anti-patterns I have outlined, hardcoded waits, God Page Objects, XPath-first locators, inheritance-heavy architectures, and manual browser management, are not just technical debt. They are mental models that no longer serve you.

The teams that get the most value from Playwright are the ones that approach it with fresh eyes. They learn the framework philosophy, embrace its conventions, and let go of the patterns that Selenium forced upon them. They write tests that are shorter, clearer, and more resilient. They ship faster because their CI pipelines are not clogged with flaky tests.

If you take one thing from this article, let it be this: the cost of carrying old patterns to a new tool is higher than the cost of learning new patterns. Invest the time to unlearn. Your future self and your team will thank you.

Frequently Asked Questions

What are the most common anti-patterns teams carry from Selenium to Playwright?

The five most common anti-patterns are: using waitForTimeout as a Thread.sleep replacement instead of expect assertions, building God Page Objects with 500+ lines instead of component-based architecture, relying on XPath-first locator strategy instead of semantic getByRole, using inheritance-heavy base classes instead of Playwright fixtures and composition, and manually managing drivers and browsers instead of using built-in context isolation. Each of these patterns was a reasonable solution in the Selenium ecosystem but becomes an anti-pattern when carried to Playwright because Playwright provides built-in solutions that are more reliable and require less code.

How do I replace Thread.sleep and waitForTimeout in Playwright tests?

Replace all explicit waits and sleeps with Playwright expect assertions. Use await expect(locator).toBeVisible() to wait for elements, await expect(locator).toHaveText() to wait for content, and page.waitForResponse() to wait for network requests. Playwright auto-wait mechanism handles synchronization automatically by checking that elements are visible, stable, enabled, and receiving events before interacting with them.

Should I use Page Object Model when migrating from Selenium to Playwright?

Yes, the Page Object Model pattern is still valuable in Playwright, but you should restructure your Page Objects. Instead of monolithic God Page Objects with hundreds of lines, adopt a component-based architecture where each UI component (search bar, navigation, cart) is its own class. The Page Object becomes a thin orchestration layer that composes these components. Use Playwright fixtures for setup and teardown instead of inheritance-heavy base classes.