Playwright provides powerful, auto-waiting assertions that make tests more stable and reliable. Using the expect() API, Playwright automatically waits for conditions to be satisfied before failing a test. Assertions retry until they either pass or reach the timeout limit, so manual waits are not required in most cases.
This section covers the most commonly used Playwright assertions with simple examples and best practices for beginners.
Basic Syntax
Syntax Explanation
expect(): Playwright’s assertion API
target: Can be a locator, page, or API response
matcher: The assertion method (for example: toBeVisible, toHaveText)
expectedValue: The value you want to validate (text, URL, count, etc.)
Visibility Assertions
Use these to check whether an element is shown or hidden on the page.
Text Assertions
toHaveText() checks exact text
toContainText() checks partial text
Attribute Assertions
Useful for validating element attributes or CSS classes.
Input Field Assertions
Commonly used for input boxes, text areas, and forms.
Enabled / Disabled Assertions
Helpful for validating buttons and form controls.
Checkbox & Radio Button Assertions
Works for checkboxes and radio buttons.
Count Assertions (Multiple Elements)
Used when validating lists, tables, or repeated elements.
Page-Level Assertions
Validates browser-level properties like URL and page title.
Assertion with NOT Condition
Used when verifying something should not happen.
API Response Assertions
Soft Assertions (Continue Test on Failure)
Test continues even if the assertion fails. Useful for reporting multiple issues in one test
Best Practices for Beginners
- Prefer Playwright assertions over manual waits
- Assert what the user sees, not implementation details
- Keep assertions in test files (page files focus on actions)
- Use toContainText() instead of toHaveText() when text may change