Lesser known Cypress.io tricks

by Filip Hric, 21 September 2020

3 min read


As I create my courses and use Cypress on my own, I often come across undocumented or not so widely used features that you might find helpful. Let’s jump into them.

Routing numbered route

When using .route() command to match your path, you can use wildcards to math the exact api call you need. But sometimes it is just not enough. Your app may call the exact same endpoint twice. To write your test for these types of situations, you can select them both using an array, like this:

cy
  .server()
  .route('POST', '/todos')
  .as('createTodo')

cy
  .visit('/')

// create 2 todos via UI using custom command
cy
  .addTodo()
  .addTodo()

cy
  .wait(['@createTodo', '@createTodo']).then( todos => {

    expect(todos[0].status).to.eq(201)
    expect(todos[1].status).to.eq(201)

  })

Instead of using an array though, you can select just the second instance of routed network request. This can be done by appending the index number on to the alias itself, like this:

cy
  .server()
  .route('POST', '/todos')
  .as('createTodo')

cy
  .visit('/')

// create 2 todos via UI using custom command
cy
  .addTodo()
  .addTodo() // we will wait for a request that happens after this action

cy
  .wait('@createTodo.2').then( todos => {
    expect(todos.status).to.eq(201)
  })

Aliasing DOM element

Routing your network calls is one of the most powerful features in Cypress. To alias them, you can use .as() command, and then use .wait() or .get() command to write a test for that network request.

You can alias your DOM elements in the same way and then use .get() command to select that element later in your test. This is especially useful when you have a list of items on the same level. For example, when using cypress-drag-drop plugin to drag an element onto another.

cy
  .get('.todo')
  .eq(2)
  .as('third')

cy
  .get('.todo')
  .eq(3)
  .as('fourth')

cy
  .get('@third')
  .drag('@fourth')

Custom formatting of .log() messages

I believe that you should write end to end tests as user stories. That is why it is vital that I understand where that story got interrupted on failed test. I have been playing around with ways to create a custom error message for some time now. Mainly because it helps a lot when debugging a failed test from screenshot, or basically captioning an end to end test. There is a way you can customize these messages using markdown formatting syntax.

cy.log('normal')
cy.log('**bold**')
cy.log('_italic_')
cy.log('[blue](<http://example.com>)')

Custom error messages

Beside custom .log() messages, you can customize your error messages too. I was thrilled to find out that expect() function can actually take a second parameter, which will become an error message on failure.

cy
  .get('.todo')
  .then( todo => {
    expect(todo, 'Milk was not found').to.contain.text('Buy milk')
})

Bonus tip: Make your DevTools open automatically in Cypress GUI:



Want to learn Cypress? Join the upcoming workshop!

Learn the core concepts, best practices and how write stable tests! Four sessions packed with great tips and on a live online workshop where you’ll learn by writing code, solving testing problems and getting your hands on Cypress. Register here!

Cypress course intercept