Skip to main content
If you’re using Playwright for end-to-end testing, you should check out Playwright Check Suites and start testing in production.
Every script that we will write will almost certainly do three key things:
  1. Navigating to some web page
  2. Waiting for something
  3. Possibly getting a timeout 😐
Initial navigation to any page can happen in multiple ways.
  • Whenever your code does a page.goto(), or a page.click() on a link, you explicitly trigger a navigation.
  • The webpage you are on can also trigger a navigation by executing location.href= 'https://example.com' or using the history.pushState() API.
In the example below we trigger two navigations:
  1. The initial load of the page.
  2. A navigation to the shopping cart by clicking a link
basic-browser-navigation.spec.ts
import { test } from '@playwright/test'

test('basic navigation', async ({ page }) => {
  await page.goto('https://danube-web.shop/')
  await page.click('#cart')
})
Run this example as follows: 
npx playwright test basic-browser-navigation.spec.ts

​
Waiting

Waiting for something to happen is a crucial part of any automation script. In most cases, this is handled automatically by Playwright. For example, when you click a button, Playwright will wait for that button to be clickable before it actually clicks it. In the example below, we type an email address into an input field on a login modal. Playwright’s fill method comes with built-in waiting functionality.
basic-browser-waiting.spec.ts
import { test } from '@playwright/test'

test('basic built-in waiting', async ({ page }) => {
  await page.goto('https://danube-web.shop/')
  await page.getByRole('button', { name: 'Log in' }).click()
  await page.getByPlaceholder('Email').click()
  await page.getByPlaceholder('Email').fill('test@test.com')
})
Run this example as follows: 
npx playwright test basic-browser-waiting.spec.ts
Playwright actions perform so-called actionability checks before interacting with DOM elements. If you call click() on a locator, Playwright will ensure that:
  • your locator resolves to exactly one element.
  • the matching element is visible.
  • the matching element is stable.
  • the matching element can receive events and is not covered or obscured by other elements.
  • the matching element is enabled.
Playwright’s auto-waiting and actionability checks allow you to focus on the end-to-end test flow without worrying when and if elements become visible. Playwright evaluates this for you.

​
Timeouts

The page.waitForNavigation() method — but also similar methods like page.reload() and page.goBack() — all take some options that determine “how” it should wait and what the timeout limits are. These options come in two flavors: 1. Hard timeout The time in milliseconds passed as the timeout property e.g. page.waitForNavigation({ timeout: 2000 }). We do not recommend using this if you do not explicitly need to. 2a. DOM event based These two options are directly related to the events your browser emits when it has reached a certain loading stage.
  • load: This is the page.goto() default and very strict: your whole page including all dependent resources, i.e. images, scripts, css etc.
  • domcontentloaded: less strict: when your HTML has loaded.
2b. Heuristic based This option is based on the heuristic that if (almost) all network connections your browser has are no longer active, your page has probably finished loading.
  • networkidle: consider navigation to be finished when there are no more than 0 network connections for at least 500 ms.
Relying on networkidle is discouraged because it slows down your end-to-end tests. It’s recommended to rely on auto-waiting and application state to evaluate when a page is ready.
Bugs don’t stop at CI/CD. Why would Playwright? Playwright logo
Sign up and start using Playwright for end-to-end monitoring with Checkly.

​
Further reading

  1. Waits and Timeouts
  2. Playwright general navigation docs
  3. Playwright auto waiting