Using Playwright Test
Checkly natively supports running browser checks using Playwright Test Runner, allowing you to write tests and use assertions using the popular testing framework. Read more on how to utilise Playwright Test best in the official documentation.
Playwright Test Runner elevates your monitoring and debugging experience by providing a number of neat functionalities:
- detailed trace files with step-by-step information on your test cases
- video recordings of browser sessions
- the
expect()
function comes with built-in awaiting - lots of web-first assertions like
toContainText
,toHaveURL
- high-level locators like
getByTitle
,getByRole
- independent nested test cases that make your Checkly check even more powerful
Playwright Test is available from runtime 2022.02 onwards.
@playwright/test
) will currently run around 30-50% longer than a regular Playwright check (playwright
). This is caused by the automatic creation of trace and video assets. We are aware of this and are investigating solutions. If this is significantly degrading the performance of your check, we recommend to divide longer tests into multiple checks.Features
This is the list of Playwright Test Runner features that are currently supported. We will update it as more features become supported.
Feature | Supported? |
---|---|
Trace files | Yes |
Video recordings | Yes |
API testing | Yes |
Custom fixtures | Yes |
Reporters | Only JSON, more to come |
Typescript | Yes |
Global configuration | No |
Visual comparisons | No (Current feature request) |
Test retry | No Enable Checkly’s “Double-check on failure” in the check settings to retry a check. |
Parallelism and sharding | No |
Browser check with multiple test cases
One of the key benefits of using Playwright Test is that you can split your check into multiple independent test cases,
and group them using the test.describe
function. Your Checkly check will fail if at least one of the test cases fails.
import { test } from '@playwright/test';
test.describe('two tests', () => {
test('one', async ({ page }) => {
// ...
})
test('two', async ({ page }) => {
// ...
})
})
const { test } = require('@playwright/test')
test.describe('two tests', () => {
test('one', async ({ page }) => {
// ...
})
test('two', async ({ page }) => {
// ...
})
})
Hooks
Playwright Test Runner offers hook functions such as test.afterEach
and test.beforeEach
that run before or after individual test cases or test.afterAll
and test.beforeAll
that run before or after all tests have started/finished.
You can find more information on available methods in the official documentation.
Viewing trace files
When a @playwright/test
test case fails, Checkly will record and make its trace files available via the UI. You can download the trace files for manual inspection or view them directly with trace.playwright.dev.
Using the Playwright Trace Viewer you can effortlessly view your test, skip back and forth between actions, view snapshots and metadata, and more. This makes it very easy to inspect individual traces and debug failing tests.
When running tests from the editor page, trace files are always available for download and preview, regardless of whether the check is passing or failing. For scheduled check runs traces are only preserved when the check failed.
Video recordings
When a @playwright/test
test case fails, Checkly will record a video for each page navigation and make it available in the UI. It is a great tool to get a first look of the actions and their outcome to quickly identify what failed, and to visualize regressions.
Here’s an example of a Playwright Test script that fails, and provides a video of the test sequence.
When running tests from the editor page, video files are always available for download and preview, regardless of whether the check is passing or failing. For scheduled check runs videos are only preserved when the check failed.
PageObject Model (POM)
If you are structuring your test codebase following the PageObject pattern, you can use the Checkly CLI out of the box. Just make sure that:
- the folder you initialize your CLI in when building your project sits above your test spec files and their dependencies
- your
testMatch
is pointing to the path(s) where your test specs live
To see one way this can look like, see our example repository.
You can contribute to this documentation by editing this page on Github