Test Automation Blog

Tools, Tips and Thoughts for Playwright, Selenium UI and API automated testing

Improve your testing with Playwright soft asserts

Sometimes you don’t want a test to stop immediately an error is found, you want it to carry on performing other related tests. To achieve this in Playwright you can use ‘soft’ assertions.

A Typical Scenario:

Let’s say you want to verify that a product’s price details are displayed correctly, including the local sales tax. In this scenario you might want to verify the product price, the sales tax %, the tax amount and finally the total price including tax.

Although purists might recommend that every test should only test one thing, in practice – including in this example – testing multiple related items can make sense in some circumstances. It also helps reduce the total amount of tests in a test suite.

The Problem We’re Solving

Without ‘soft’ assertions, a Playwright test might look like this:

test('sales tax is calculated correctly on product page', async ({ page }) => {
  await page.goto('http://localhost:3000/product/4273676');

  await expect(page.locator('#product-price')).toHaveText("$50.00");
  await expect(page.locator('#sales-tax-pct')).toHaveText("10%");
  await expect(page.locator('#sales-tax-amt')).toHaveText("$5.00");
  await expect(page.locator('#total-price')).toHaveText("$55.00");
});

However if any of the assertions fail, then the test execution will stop and subsequent assertions will not be made. This leaves test scenarios not covered until the failed test has been fixed.

To remedy this, soft assertions can be used instead, using the soft keyword. Modifying the test above this would look like:

test('sales tax is calculated correctly on product page', async ({ page }) => {
  await page.goto('http://localhost:3000/product/4273676');

  await expect.soft(page.locator('#product-price')).toHaveText("$50.00");
  await expect.soft(page.locator('#sales-tax-pct')).toHaveText("10%");
  await expect.soft(page.locator('#sales-tax-amt')).toHaveText("$5.00");
  await expect.soft(page.locator('#total-price')).toHaveText("$55.00");
});

In this situation all 4 assertions will always be executed, and if any fail then the test will fail. If more than one assertion fails then all of them will be output in the test report.

Note that there is no need to execute a final line of code to mark the end of the soft assertions, and output the test result.

Mixing Soft and Hard Assertions

Basically, don’t do it!

I could explain what the behavior of mixing soft and hard assertion will be, but it simply introduces a level of complexity and fragility that is not needed in automated tests. Playwright automated tests with a mix soft and hard assertions are difficult for inexperienced testers to understand, and may encourage them to not implement them correctly. In my view the current behavior is also something that may easily change in the future, requiring an experienced QA to fix.

Other Common Scenarios for Soft Assertions

Here are some examples of where using soft assertions in Playwright automated tests can be helpful.

Table column headings

Having a ‘smoke’ test to verify that a HTML table’s structure is correct can be very useful, before other tests dig into the table’s content. A useful check is to make sure all the expected columns appear, with the correct titles. Using soft assertions is valuable to ensure all columns are verified.

Comparing expected vs actual data in a table

In addition to a ‘smoke’ test to verify a table’s basic structure, if the table contents itself needs to be checked then soft assertions allows the test to log everything wrong in one go – not stop at the first incorrect cell.

Validating multiple fields on a form

A user registration form may have many field the user needs to enter, for example name, email, telephone number, password, address, date of birth, etc. A single test that verifies each of these fields is visible and contain the correct label text would benefit from using sort assertions.

Running accessibility checks (e.g., ARIA roles, alt text)

Accessibility tests often include dozens of independent checks:

  • All images have alt text
  • Form fields have labels
  • Buttons have roles
  • No duplicate IDs

You want a full accessibility error report, not one failure at a time.

Checking multiple API results on a page

If a dashboard loads many independent API widgets:

  • Recent orders
  • Analytics graph
  • Notifications
  • Profile card

These may fail separately – soft assertions give you a complete map of what broke.

Validating an internationalised page

When switching languages:

  • All headings updated
  • All menu items translated
  • Buttons have correct text
  • Dates/currencies formatted correctly

One missing translation shouldn’t hide the rest.

Ensuring all user permissions render correctly

Admins vs users vs managers may see:

  • Different menus
  • Different buttons
  • Different warnings
  • Different actions

Soft assertions let the test verify the entire permission matrix instead of only the first missing item.

And Finally…

Soft assertions are a useful tool that allows a Playwright test to continue after any single assertion fails.

However we should take care NOT to abuse this as a way to write messy tests that verify too many different scenarios – simply because it’s convenient. Instead we should remember why we create separate tests and ensure that as a group they form a test suite that is well structured, with a logical integrity.

Improve your testing with Playwright soft asserts
Scroll to top