How to add Playwright tests
Installation
Section titled “Installation”Playwright is installed with the repository dependencies, but its browser binaries must be installed separately. Run this command before your first local test run and after Playwright is upgraded. On Linux, it also installs the required system dependencies:
pnpm run playwright:install-build-toolsTo learn how to write Playwright tests, or ‘specs’, please see Playwright’s official documentation.
Where to Add a Test
Section titled “Where to Add a Test”-
Playwright tests are in the
./e2edirectory. -
Standard Playwright test specs use the
.spec.tsextension.
Best Practices for writing E2E tests
Section titled “Best Practices for writing E2E tests”This section will explain in detail about best practices for writing and documenting E2E tests based on Playwright documentation and our community code-style.
Imports
Section titled “Imports”Import test and expect from @playwright/test for tests that do not change user data:
For example:
import { test, expect } from '@playwright/test';Tests that change user data should use the isolated-user fixture. It creates a separate user for the test and deletes that user afterward. Import test and expect from the fixture, then select a user preset if the test needs one:
import { test, expect } from './fixtures/isolated-user';
test.use({ userPreset: 'certified' });Identifying a DOM element
Section titled “Identifying a DOM element”Playwright comes with multiple built-in locators, but we recommend prioritizing the following locators:
getByRolefor querying semantic elements, whose role is important and allows assistive technology to perceive the page correctly.getByLabelfor querying form controls by their associated label.getByPlaceholderfor querying form controls when no label is available.getByAltTextfor querying images and other elements by their alternative text.getByTextfor querying non-semantic elements such asdiv,span, orp.
For example:
await expect(page.getByRole('heading', { name: 'Sign up' })).toBeVisible();await expect(page.getByText('Hello World')).toBeVisible();If an element cannot be queried with an appropriate user-facing locator, you can use the data-playwright-test-label attribute as a last resort. This attribute should be used only in Playwright tests, and not for styling or any other purposes.
For example:
<div data-playwright-test-label="landing-page-figure"> <img src="..." alt="..." /></div>In the test file, you can use the getByTestId method to identify the element.
For example:
await expect(page.getByTestId('landing-page-figure')).toBeVisible();Constants
Section titled “Constants”Define any constant elements, data sets, or configurations used throughout your tests for easy reference.
For example:
const landingPageElements = { ... };const superBlocks = [ ... ];Descriptive test names
Section titled “Descriptive test names”Each test block should have a clear and concise name describing exactly what it’s testing.
For example:
test('The component landing-top renders correctly', async ({ page }) => { // ...});Human readable assertions
Section titled “Human readable assertions”Each assertion should be as human readable as possible. This makes it easier to understand what the test is doing and what it’s expecting.
For example:
await expect( page.getByRole('heading', { level: 1, name: 'Learn to code — for free.' })).toBeVisible();Keep it DRY
Section titled “Keep it DRY”Make sure that the tests are not repeating the same code over and over again. If you find yourself repeating the same code, consider refactoring it as a loop or a function.
For example:
const expectedLogoCount = 3;await expect(logos).toHaveCount(expectedLogoCount);
for (const logo of await logos.all()) { await expect(logo).toBeVisible();}Tests for mobile screens
Section titled “Tests for mobile screens”Use the isMobile argument to test logic that is specific to mobile devices.
For example:
test('The campers landing page figure is visible on desktop and hidden on mobile view', async ({ page, isMobile}) => { const landingPageFigure = page.getByTestId('landing-page-figure');
if (isMobile) { await expect(landingPageFigure).toBeHidden(); } else { await expect(landingPageFigure).toBeVisible(); }});Group related tests
Section titled “Group related tests”Group related tests together using test.describe blocks. This makes it easier to understand what the tests are doing and what they’re testing.
For example:
test.describe('The campers landing page', () => { test('The campers landing page figure is visible on desktop and hidden on mobile view', async ({ isMobile }) => { // ... });
test('The campers landing page figure has the correct image', async () => { // ... });});How to Run Tests
Section titled “How to Run Tests”Ensure that MongoDB and Client Applications are Running
Section titled “Ensure that MongoDB and Client Applications are Running”Playwright’s setup project creates the shared certified and development users before the tests run. Tests that import the isolated-user fixture create and remove their own users.
Run the Playwright Tests
Section titled “Run the Playwright Tests”To run tests with Playwright, check the following commands:
-
To run tests in UI mode:
Terminal window pnpm playwright:watch -
To run a single test:
Terminal window pnpm playwright:run <filename>For example:
Terminal window pnpm playwright:run landing.spec.ts -
To run a set of test files:
Terminal window pnpm playwright:run <filename1> <filename2>For example:
Terminal window pnpm playwright:run action-row.spec.ts landing.spec.ts -
Run the test with the title:
Terminal window pnpm playwright:run -g "<title>"For example:
Terminal window pnpm playwright:run -g "add a todo item"
Debugging Tests
Section titled “Debugging Tests”Since Playwright runs in Node.js, you can debug it with your debugger of choice e.g. using console.log or inside your IDE
-
Debugging all tests:
Terminal window pnpm playwright:run --debug -
Debugging one test file:
Terminal window pnpm playwright:run example.spec.ts --debug
Generate Test Reports
Section titled “Generate Test Reports”The HTML Reporter shows you a full report of your tests allowing you to filter the report by browsers, passed tests, failed tests, skipped tests and flaky tests.
pnpm --dir e2e exec playwright show-report playwright/reporterTroubleshooting
Section titled “Troubleshooting”-
Playwright reports a connection error when the client is not available at its configured base URL. The default URL is
http://127.0.0.1:8000.Terminal window Error: page.goto: Could not connect: Connection refused=========================== logs ===========================navigating to "http://127.0.0.1:8000/", waiting until "load"============================================================Check these items before running the test again:
- Confirm that the client and API are running.
- Open
http://127.0.0.1:8000in your browser. - If you changed
HOME_LOCATION, confirm that it points to the running client.
For other errors, see Playwright’s test debugging guide.
Set up for Playwright on GitHub Codespaces
Section titled “Set up for Playwright on GitHub Codespaces”Ensure Development Environment is Running
Section titled “Ensure Development Environment is Running”Follow the GitHub Codespaces setup instructions. The codespace creates .env, starts MongoDB and Mailpit, and seeds the database. Playwright creates its test users when the tests run.
Start the client and API if they are not already running:
pnpm run developInstall Playwright Build Tools
Section titled “Install Playwright Build Tools”To install necessary dependencies for running Playwright run the following command:
pnpm run playwright:install-build-toolsRun the Playwright Tests on GitHub Codespaces
Section titled “Run the Playwright Tests on GitHub Codespaces”To run all Playwright tests, run the following command:
pnpm playwright:run