Lesser known Cypress.io tricks

Filip Hric
Sep 21 · 3 min read

Cypress.io is pretty amazing, and if you haven’t used it yet and need a jump start, I recommend my super-quick straight-to-the-point course on Udemy. It’s called Cypress test automation for people in a hurry and it’s exactly that. Average video length is 2 minutes, and then it’s practical exercises that help you learn more.

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:

Image for post
Image for post

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:

Image for post
Image for post

Pro tip: did you know Cypress recently released experimental full-layer network stubbing? Besides xhr requests, you can now route images, static files and fetch requests!

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.

Image for post
Image for post

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.

Image for post
Image for post

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.

Image for post
Image for post

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

Hope these helped. If you enjoy working with Cypress, here at Slido, we are using it a lot and are currently looking for new colleagues. Check out our open job positions here.

Slido developers blog

Code is poetry

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store