How to Assert an Element Is NOT on the Page in Playwright

To assert that an element is not on the page in Playwright, use toHaveCount(0) when no matching element should exist in the DOM. If the element may remain in the DOM but should not be visible, use toBeHidden() instead.

Leapwork Play gives you a more explicit workflow: make the expected result a named Validate step for example, Verify no payment error while keeping Playwright underneath.

Try Leapwork Play →

How do you validate that an element is not present in Play?

In Play, the expected result can be represented as a named Validate step.

For example:

await leapwork.step(
  'Verify no payment error',
  async () => {
    await expect(
      page.getByTestId('payment-error')
    ).toHaveCount(0);
  },
  { action: 'validate' }
);

The underlying assertion remains Playwright, but Verify no payment error is now an explicit validation in the test flow rather than an unnamed negative assertion inside a larger block of code.

Leapwork Play makes an expected result an explicit Validate step while keeping the underlying assertion in Playwright.

Choose the right assertion

Use the assertion that matches what the user should experience:

What should happen	Use
The element should not exist at all	`toHaveCount(0)`
The element can exist, but users should not see it	`toBeHidden()`

The distinction matters because absent and hidden are different application states.

How Play extends the Playwright workflow

With Playwright	With Play
Write the assertion directly in test code	Use the Playwright assertion as an explicit Validate step
Test intent depends on the surrounding code and naming	Give the validation a clear name such as Verify no payment error
Work with the assertion as part of the code	Work with the validation as a distinct step in the Play test flow

The assertion is still Playwright. The difference is how the expected result is represented in the test workflow.

Best practices

- Use a Play Validate step when the expected application state should be an explicit part of the test flow. Give the validation a clear name, such as Verify no payment error.
- Use toHaveCount(0) when no matching element should exist.
- Use toBeHidden() when the element may exist but should not be visible.
- Use a reliable locator before trusting a passing negative assertion.
- Verify the positive success outcome when success matters.
- Let the assertion retry instead of adding a fixed wait.

Troubleshooting

Problem	What to do
`toHaveCount(0)` passes but an error is visible	Check that the locator targets the actual error element.
`toHaveCount(0)` fails although the element looks gone	Use `toBeHidden()` if the element is hidden rather than removed.
The assertion is flaky	Assert the final outcome and avoid fixed waits.
The test passes even when the operation fails	Add a positive assertion for the expected success state.

Frequently asked questions

How do I assert that an element does not exist?

Use await expect(locator).toHaveCount(0);. This confirms that no elements match the locator.

Does `toHaveCount(0)` wait for the element to disappear?

Yes. Playwright retries the assertion until the locator has zero matches or the assertion times out.

Should I assert that an error is absent or that the operation succeeded?

When success matters, assert the positive outcome. Add the negative assertion when the absence of an error is also required.

How does Leapwork Play handle this validation?

Play keeps the underlying Playwright assertion but represents the expected result as a named Validate step, making the validation explicit in the test flow.