English for Playwright Testing
Learn the vocabulary and phrases used by QA engineers and developers when discussing Playwright tests, locators, fixtures, and assertions.
Playwright has rapidly become the go-to tool for end-to-end browser testing, and working with it means learning a specific set of English terms. Whether you are writing tests, reviewing a colleague’s pull request, or giving a standup update about a flaky spec, knowing the right vocabulary makes your communication precise and professional. This guide covers the key terms and the most natural ways to use them in real work conversations.
Key Vocabulary
Locator
A Playwright-specific object that finds and interacts with one or more elements on a page. Locators are lazy — they only resolve when you perform an action on them.
Example: “I switched from page.$() to a locator because locators have built-in auto-waiting.”
Fixture
A reusable piece of test setup provided to tests via dependency injection. Playwright’s built-in fixtures include page, browser, and context; teams also write custom fixtures for shared login state or API clients.
Example: “I extracted the authenticated session into a fixture so we don’t repeat the login flow in every test.”
Assertion
A statement that checks whether the application is in the expected state. Playwright uses expect() with web-first matchers that automatically retry until the condition is met or a timeout is reached.
Example: “The assertion waits up to five seconds for the element to become visible before it fails.”
Page Object Model (POM)
A design pattern that wraps page interactions in a dedicated class, separating test logic from selector details. Changes to the UI only require updating the page object, not every individual test.
Example: “We have a LoginPage class in our POM — update the selector there and all tests will pick it up.”
Network Interception
The ability to intercept, inspect, modify, or mock HTTP requests and responses during a test. In Playwright this is done with page.route().
Example: “I used network interception to stub the payment API so the test doesn’t charge a real card.”
Trace A detailed recording of a test run that includes a timeline, screenshots at every action, network requests, and console logs. Traces are invaluable for debugging failures in CI. Example: “The test was green locally but red in CI — I opened the trace and saw the modal was rendering 200ms late.”
Parallel Execution Running multiple tests or test files at the same time across separate browser workers to reduce total test suite duration. Example: “We cut the pipeline from 12 minutes to 4 by enabling parallel execution across four workers.”
Flaky Test A test that passes and fails inconsistently without any change to the code under test. Flakiness is usually caused by timing issues, shared state, or environment differences. Example: “That spec has been flaky all week — let’s add a proper assertion instead of relying on a hard-coded wait.”
Common Phrases
In code reviews:
- “This locator is too broad — it will match multiple elements if the page changes. Can we use
getByRoleorgetByTestIdinstead?” - “I’d move this setup into a fixture so it’s reusable across the suite.”
- “The assertion here should use
toBeVisible()rather than checking the DOM directly — it gives you auto-retry for free.”
In standups:
- “I’m investigating a flaky test in the checkout flow — the trace shows a race condition on the payment button.”
- “All end-to-end tests are passing; I’m now enabling parallel execution to bring the pipeline under five minutes.”
- “I added network interception for the third-party analytics endpoint so our tests don’t depend on an external service.”
In documentation:
- “Each test receives a
pagefixture pointing to a fresh browser context — no state leaks between tests.” - “Traces are uploaded as CI artifacts on failure; open the
.zipin the Playwright Trace Viewer to replay the test step by step.” - “Custom fixtures are defined in
fixtures/index.tsand extended from@playwright/test.”
Phrases to Avoid
Saying “the test waits for the element” — The more precise phrasing is “the locator retries until the element is visible” or “the assertion polls until the condition is met.” Playwright does not use passive waits; it uses smart retries.
Saying “mock” when you mean “intercept” — A mock replaces the entire dependency; interception lets the real request go through but can modify it. Say “I intercepted the request and modified the response” rather than “I mocked the request.”
Saying “the test broke” — In English, tests fail, not break. “The test failed in CI” is correct. “Broke” sounds informal and is less precise. Reserve “broke” for when a code change broke the application itself: “the refactor broke the login flow.”
Quick Reference
| Term | How to use it |
|---|---|
| locator | ”Use a role-based locator to keep tests resilient to CSS changes.” |
| fixture | ”Our auth fixture handles login once and shares the cookie across all tests in the file.” |
| assertion | ”The assertion timed out — the element never reached the expected state.” |
| trace | ”Grab the trace from the CI artifact and open it in Trace Viewer.” |
| flaky test | ”We tagged it as flaky and opened a ticket to investigate the root cause.” |