A pragmatic approach to QA and OPS

Some Useful Assertions in Playwright – Part -1

Let’s talk about assertions. Assertions are one of the key component of any testing framework. Assertions allows us to assert or in simple words – compare something – an expected value with the one that is actual.

Most of the test frameworks like TestNG, JUnit, pytest, NUnit etc. give the ability to apply a range of different asserts in the tests, thereby increasing the realiability of the tests and allowing the QA folks to check whether the expected outcome matches the actual outcome.

In Playwright, the default test runner, gives us a host of different assertions, which makes the job of us, QA people more easier than ever to assert some checks on the AUT (Application Under Test).

Note: These assertions can be applied using both soft and hard methods – which I have talked about in my LinkedIn post here. Also I’ve checked this with the default test runner provided by Playwright JS.

  • toBeChecked()

You can use this assertion to check that the locator is pointing to a checked input – particularly helpful when you want to assert that you have checked an element – may be a checkbox.

Syntax :

  • toBeDisabled()

You can use this assertion to assert that the locator in question points to an element that is disabled. It may have been disabled using the inline disabled HTML attribute or may have been done using the aria-disabled attribute.



One of the things that I missed having in Puppeteer was the able to have these kinds of assertions. I’ve a very popular SO question, where I wanted to check if an element is disabled. So this assertion would have definitely helped me there.

  • toBeEditable()

If you want to assert that the element is editable or not, then you can use this assertion.

Syntax :


  • toBeEmpty()

Suppose you want to validate that the input element that you want to target is empty and has no text – then you can use this assertion. Also you can use this to assert whether the element under question points to any empty element on the DOM tree node.

Syntax :

  • toBeEnabled()

Just the direct opposite of the toBeDisabled() assertion- you can assert if the element is in enabled state using this assertion.

Syntax :


  • toBeFocussed()

If you want to assert that the element in question is focussed on screen, then you can use this assertion.

Syntax :


  • toBeHidden()

Let’s say you have a element on webpage, and you want to test that it is hidden – then you can use this assertion- a typical example is asserting that the loader on the webpage is now hidden.



The condition of visibility of an element is one of the actionability checks that Playwright performs. You can also check that here.

  • toBeInViewPort()

If you want to assert that the element under test, is visible on the browser viewport, then you can use this assertion. This assertion was released with the version v1.30 of Playwright.

Syntax :


Now, you can also use a ratio option inside of this assertion to assert how much of the element is inside the view port – let’s say you want to assert that the element is at least 50% inside the viewport, then you can use

Syntax :

expect(locator).toBeInViewport({ratio: 0.5})

  • toContainText()

So we have the toBeEmpty() assertion to assert if the element has no text. If you want to assert the opposite, that means you want to assert if an element contains certain text, then you can use toContainText() assertion.

Syntax :


This can also accept a regex to match the text like

expect(locator).toContainText(/\d messages/);

This can be very useful when you’re trying to assert the text contained in a list of elements – let’s say a drop down, because you can send an array of text to match too – however that should be in order.

await expect(page.locator('ul > li')).toContainText(['Text 1', 'Text 2']);

This assertion again customisable in the sense that you can pass options to ignore the case when comparing and also can provide whether to fetch text using the element.innerText property or the element.textContent property when getting the text .

Read about this assertion here.

  • toBeVisible()

The exact opposite of the the toBeHidden() assertion. If you want to assert the visibility of an element, this might be a good assertion on an element.

Syntax :


  • toHaveAttribute()

If you want to assert on an element, to have certain HTML attribute , then you can use this assertion. Let’s say you want to assert that an input element on this SelectorsHub testing page, has type of email then you can use this


expect(locator).toHaveAttribute(aatributeName, attributeValue);

For e.g – in the situation mentioned above –

await expect(page.locator(#userId)).toHaveAttribute('type','email');
  • toHaveClass()

This assertion can be used to assert if an element contains certain CSS classes. This assertion can be used to match a single class or an array of classes ( in which case all the classes will be matched) .

<div class='selected row' id='component'></div>

For this code above, we can use the toHaveClass() assertion as

expect(page.locator(#compoent)).toHaveClass('selected row')

In case you’re passing an array of values, it would match all the values in the array and would fail if any of the classes is not matched.

In the next series, we will take a look at some of the other assertions in Playwright. Stay tuned for the next series on Playwright assertions. If you have any request or any suggestion/question on any topic on Playwright, feel free to use the comments section.

%d bloggers like this: