Cypress - Web Testing Automation Of 21st Century?

“The web has evolved. Finally, testing has too.” These two sentences not only describe the world which we, QAs, live in. They also sum up the tool that I want to talk about today. 

I admit it, I took the liberty of copying them from the page of the company that created the framework. I did it to both tease you about it and prove that it’s more than just an ad. It’s the truth. 

Gone are the days when Selenium was the jack of all trades in the industry. Now other tools take its place, some better, some worse. One stands out though. Ladies and gentlemen - here is Cypress.

A Newcomer in Web Automation

What is Cypress exactly? 

Well, it’s an all-in-one tool used to run end-to-end tests on web apps. That means you no longer have to configure your framework, your assertion library, your Selenium wrapper etc. separately. Instead, you get a package with everything ready from the get-go. 

It doesn’t use Selenium, being based on its own architecture instead, thus avoiding a lot of Selenium-based errors. Because it’s focused on web apps that are based greatly on JavaScript, Cypress also executes tests in JS (although TypeScript is also accepted if you feel like using it instead). 

Learn more about Web App Testing Services.

That, in turn, makes work easier both for devs and QAs due to language familiarity.
What probably makes it stand out the most is its “time travel” ability. While there are some other frameworks that simplify your work by e.g. also automatically waiting for an element to be visible/active (yup, I’m talking about you, TestCafé) the ability to “go back in time” is unique to Cypress.

 You can “go back” to every command Cypress executed and check the application’s state before and after it was issued. That way you can see what your script saw at that moment.

time-travel example CypressTime Travel Example in Cypress

Another great addition, albeit somewhat irritating at times, is the ability to automatically restart tests. Whenever you make a change to your code, no matter how insignificant, your currently open spec(s) will automatically run again. That way you can immediately see changes you made being reflected in tests. This can greatly improve your debugging times.

A small, yet very helpful feature, is the “Playground Selector”. While not accurate 100% of the time, it will take care of finding selectors for you. You no longer have to build them, instead just use what Cypress proposes.

Cypress - An Ease Of Use

Now that you’ve heard about the tool, let’s take a look at some simple tests you can write. I won’t guide you through the configuration etc., because the team has a great tutorial for it right here. Below I will just use the examples they provided on their page and describe them.

The shortest test you can write would probably look like this: 

passing test in cypress

passing-test-examplee in cypressPassing Test Example in Cypress

This is the simplest test you can create. What it does is next to nothing (a basic assertion), but it’s useful to get familiar with the tool. By the way, instead of writing 
you can also  write 
assert.equal(true, true).

Similarly, you can write a failing test in the same manner: 

failing-test-example in cypressFailing Test Example in Cypress

As you can see, our previously “green” test is now “red” with Cypress also writing down the error below. These errors usually point you exactly to where the problem is so it’s easier to debug them. 

This is how a “real life” test would look like (I added more comments for clarity): 

real life test

real life test example in cypress
 Real Life Test Example in Cypress

As you can see, it’s an easy test. First, we tell our script to visit Then, we search for a specific element and click on it. After that we assert that the URL has actually changed. Next, we type to the .action-email input field. Lastly, we check this field’s value.

Note how at the end of the test we chain all the commands off of the previous ones. Basically, almost every command can be chained off like this. However, we need to remember that most of those chains have to start with cy.get() . That way our test will know what element to work on.

Obviously, there are a lot of other things Cypress can do. For the sake of simplicity though, I just focused on the basics. If you would like to learn more, then I invite you to check their documentation. You can find it here.

A problem child

Unfortunately, just like every other tool, Cypress also has some flaws.

The biggest of them is the lack of cross-browser testing support. While it is being slowly introduced (with Firefox getting more and more support in the recent versions) it’s still a long way to go. 

For now you can only use either Chrome or Electron (and, as mentioned before, Firefox, though to a certain degree). While it isn’t really the reason to abandon the tool completely, it’s worth knowing that it’s still missing some things. [UPDATE] Since version 4.0.0 Cypress fully supports Google Chrome, Electron, Microsoft Edge (Chromium version) and Firefox (though it is still in Beta phase).

Despite its support for React apps, Cypress sometimes gets lost when working on them. This is most often represented in it incorrectly loading the changing (animated) layout, breaking it completely and failing the test. 

Surprisingly, recreating the same action in the Cypress’ UI manually does not yield the same result.
With Cypress bundling a couple of tools you have to keep in mind that some of them will eventually become outdated. While not really that problematic most of the time, this can be an irritating thing in some situations (for example, when have.focus  assertion was broken). 

Indeed, the team tries to keep everything up-to-date(ish), but sometimes changes introduced force them to stick to the older version. This eventually leads to some problems and requires hacking (with the example mentioned before being already fixed in newer versions) to solve some problems. Consider it a cost of not having to update anything yourself.

Because Cypress depends greatly on asynchronous solutions and callbacks, you are eventually going to face callback hell, especially if you want to hold, for example, a text value of multiple elements for later use. 

In that case, instead of writing something like this:

await async approach in cypress You have to write something like this:

closures approach in Cypress
Basically, whenever you hold a reference to some element (e.g. its text) you have to do the rest of your test in that callback until you compare this value or use it again. If you don’t do it, you won’t be able to access these references.

Now imagine having more than three elements here. Callback hell indeed. And no - before you ask, you CAN’T use async/await instead. Yes, it is readable...ish. But definitely doesn’t look good.

Possible alternatives for Cypress

The first thing that comes to my mind that you can use instead is TestCafe. It uses a similar waiting logic to Cypress’ while also supporting cross-browser testing. 

It may be somewhat cumbersome to use at first, especially if you’re not familiar with async/await, while also lacking a great runner interface, but aside from that it’s just as powerful as Cypress. 

In certain situations, it can even outperform it. Whatever the reason may be for you to stop using Cypress, you can safely go with TestCafe.

testcafe example

Test Cafe Example

If you don’t mind a little bit of fiddling before writing your tests then you can also check out While it requires more configuration (you can use boilerplate projects though) it’s also an easy to use and a very reliable tool.

Both of the tools mentioned here also use JavaScript/TypeScript, which makes them stand out. Of course, if you feel brave, then feel free to use Selenium. Though with such a broad range of other tools, why would you even want to? ;)

An ultimate solution for Web App Testing?

Despite all its flaws, Cypress is a great tool, definitely worth checking out. It’s easy and fun to use, it has a great community and support from both them and the people developing the tool, it’s powerful. 

Seeing how the development currently goes, with all the features being added and bugs being fixed I can honestly say that it can greatly define the future of test automation!

Get started today
Grzegorz Kłos
Grzegorz Kłos - Apphawks Co-founder
© 2021 Apphawks. All rights Reserved.