Cypress Tips May 2026

Considering each possible app state, conferences, plus work with me (in Tokyo)

Every State

This month I finally decided “enough is enough”. An end-to-end test should consider every possible state after user action. Imagine visiting a page and the app loading and showing some data. What are possible states? We can make this diagram:

Web app going through three separate states: starting, loading, and showing the loaded data

Except this diagram is incomplete. What happens if the backend responds with an error? The application might ignore it, forever stuck in the “loading” state. Or the app might shown an error message, moving into the “data load error” state. The user might go back to the beginning by reloading the page.

Web app that can show any data loading errors

Even worse: most apps do not make the “data is loading” state easy to observe; no “loading…” element, no spinner, the UI is not disabled, nothing. The user just has to guess that the app is doing something and the user should wait until it reaches one of the possible final states. The “data is loading” state is implied. We can only check the “starting” and the “final” state. When checking for the “final” state, the test must check for both “success” or “error” elements.

The test can only observe the starting and the final state. The final state can have either success or error elements.

Enter “cy.depends” command from cypress-if plugin. It is an easy way of querying the DOM for multiple selectors, each selector corresponding to some final state after user action. Here is how easy we can match anything the app shows:

cy.contains('button', 'Fetch data').click()
// report success, fail on error
cy.depends({
  '#data': 'Data loaded',
  '#error': new Error('Failed to load data'),
})

You can print log message for each state, throw an error to fail the test, or run additional Cypress commands. The tests should be more complete, faster, and easier to debug. You can also write conditional tests with ease. For example, let’s ensure that a random Dialog element is closed:

it(
  'closes dialog if open',
  () => {
    cy.visit('cypress/close-dialog.html')
    cy.depends({
      'dialog[open]': ($dialog) => {
        cy.wrap($dialog).find('button#close').click()
      },
      'dialog:hidden': 'dialog is already closed',
    })

    // check if the dialog is open
    cy.depends({
      'dialog[open]': new Error('dialog should be closed'),
      'dialog:not([open])': 'closed dialog',
    })
  },
)

For more, read the blog post “DOM State Clarity With cy.depends Command“ and give “cy.depends” command a try. You can also read my older blog post “Negative Assertions And Missing States”.

Nordic Testing Days conference

Next week I will speak Nordic Testing Days conference in beautiful Tallinn, Estonia. My talk will be about our Cypress end-to-end tests and how we write and run them at Mercari US. Get a 10% discount by using promo code 0YLMC

Some of the Nordic Testing Days speakers, including me

Work with me

Speaking of Mercari US. We have a Tokyo office, and we are hiring a QA engineer for that office. Must love testing, must love automation, must love React Native application testing. Check the job posting and how we hire people blog post.

New course 🎓

Walmyr Lima e Silva Filho has published a new Cypress course, check it out: Cypress Simulator. There is an initial discounted price, looks pretty attractive.

Cheers!