When testing React applications with Playwright, you often need to handle asynchronous operations. React components frequently update their UI in response to data fetching, user actions, or delayed effects. If you do not account for these asynchronous updates, your tests can become unreliable or fail intermittently. To address this, Playwright provides several waiting strategies that help you synchronize your tests with the application’s state.

A common approach is to use waitForSelector. This method tells Playwright to pause test execution until a specific element appears in the DOM. This is useful when you expect dynamic content to render after a network request or a state change. For example, if clicking a button loads a user profile, you might wait for the profile card to appear using waitForSelector('.profile-card').

Another strategy is waitForResponse, which allows you to wait for a network response matching a specific URL or predicate. This is particularly helpful when you need to ensure that data has been fetched from the server before proceeding with assertions or further interactions. For instance, after triggering a data load, you might use waitForResponse to confirm that the relevant API call has completed successfully.

Handling dynamic content is a core aspect of end-to-end testing with React. UI elements may appear, change, or disappear based on user actions or asynchronous data updates. Combining waiting strategies ensures your tests interact with the application only when it is in the expected state, reducing the risk of failures caused by timing issues.

Best practices for avoiding flaky tests in asynchronous scenarios include always waiting for the right conditions before interacting with or asserting on UI elements. Avoid using arbitrary timeouts, as these can slow down your tests and do not guarantee reliability. Instead, prefer Playwright’s built-in waiting mechanisms, which are designed to be robust and efficient. Structure your tests so that each step depends on a verifiable change in the UI or application state, and use selectors that are stable and descriptive. This approach leads to more maintainable and trustworthy tests, especially as your application grows in complexity.

src/App.jsx

import { useState } from "react";

export default function App() {
  const [loading, setLoading] = useState(false);
  const [message, setMessage] = useState(null);

  const loadData = () => {
    setLoading(true);

    setTimeout(() => {
      setMessage("Profile loaded");
      setLoading(false);
    }, 1000);
  };

  return (
    <main style={{ padding: 24 }}>
      <button onClick={loadData}>Load Profile</button>

      {loading && <p>Loading...</p>}
      {message && <p data-testid="result">{message}</p>}
    </main>
  );
}

e2e/tests/async-operations.spec.ts

import { test, expect } from "@playwright/test";

test("loads profile after async action", async ({ page }) => {
  await page.goto("/");

  await page.getByText("Load Profile").click();

  // Auto-waiting assertion
  await expect(page.getByText("Loading...")).toBeVisible();

  // Waits until async content appears
  await expect(page.getByTestId("result")).toHaveText("Profile loaded");
});