Advantages and Disadvantages of Cypress (End to End Testing Tool) before choosing it as your Testing Automation Tool:

Let’s look at some of the characteristics of Cypress that make it a very useful end-to-end testing framework.

• The first main advantage of Cypress is that it uses a real browser to run tests. Other end-to-end testing frameworks like Selenium usually use what’s called a headless browser to run their tests, which is basically a program that simulates a browser but doesn’t actually display any user interface. Now, one of the problems here is that these headless browsers come with their own set of bugs, and real browsers that users are going to be accessing our application with, like Chrome, have a different set of bugs and quirks. And this means that the tests we run in a headless browser might not always give us the same results that our users will get when they use our application. Cypress, on the other hand, runs our tests inside a real browser, which gives us results that are almost identical to what users are going to experience.

• It also has access to the network layer over the application, which allows us to control all the network requests that go in and out of our application. And this can be extremely useful for doing things like simulating what happens when our server has an error.
• Another nice thing about Cypress is that it takes the visibility of elements into account when running tests. And this means, for example, that if we’re testing to see the behavior of a button when someone clicks it (visible: hidden;) but the button isn’t visible or is hidden behind another element, or is off the screen, Cypress will take that into account, and the test will fail. And this is something other frameworks don’t necessarily take into account, but it’s really important because users can’t click on elements that are visible. As we know that we want our end-to-end tests to very closely mirror the experience that real users will have when they use our application.

• Cypress also has a lot of access to resources that other frameworks don’t use, which means that it can do things like taking screenshots and videos of our site, while Cypress is running our tests. And this is extremely useful when tests fail since we can simply watch what happens when a certain series of steps is followed.

• And finally, one of the most obvious advantages of Cypress, is that it’s very intuitive and readable. As an example, take a look at this command

cy.get('@tet-input').type('Hello!');

Chances are, even if you’ve never worked with Cypress before, you can still tell me exactly what these lines of code are doing, they’re entering text into a text box. And this sort of readability really contributes to making Cypress a nice tool to use.

Since we’ve covered the advantages of Cypress.io, it’s only fair to take a look at some of the limitations it has as well. And knowing these limitations will help you decide if Cypress.io is the right tool for whatever task you have in mind.

• So the first idea you might have when learning about Cypress is to use Cypress as an automation tool for doing things like data mining or web-crawling. And while in theory, you might be able to build a very rudimentary web crawler with Cypress, this is something it’s not really designed to do, and there are far better tools for doing this than Cypress.

• The second limitation of Cypress comes from the very thing that makes it such a unique and useful tool. It runs inside a real browser, and this means that the only language that Cypress supports for writing tests is JavaScript, and according to them it’s the only language that they’ll ever support. Now, this does not mean that you can’t test a site written in some other language than JavaScript. You can. It just means that the tests you write will have to be written in JavaScript.

• The third limitation is that you can’t test multiple tabs or multiple browser windows at the same time. And the main reason Cypress doesn’t allow you to do that is that they believe that there’s really no good reason that you should ever need to test multiple tabs or browsers in the same test. For example, if you wanted to test that clicking a link opens the link in a new tab, you really only need to check that the link has the target=”_blank” set on. Anything further than that and you’re not really testing your app any longer. You’re testing the functionality of your browser, which is something you really don’t need to do.

• Furthermore, if you need to test the functionality of something like a chat application, which in theory requires two browsers to chat with each other, there are other methods we can use to get around this such as stubbing.

• And lastly, Cypress doesn’t allow us to visit two different superdomains in the same test. A superdomain is what you might also call a domain name like google.com or linkedin.com. Now, you can visit two different superdomains in two different tests, but not in the same test. Now, this has to do with how Cypress works under the hood, but in reality, the only time you should ever really need to visit more than one superdomain in one test is when working with things like OAuth providers, and there are workarounds for this as well.

So those are all the major so-called permanent trade-offs of Cypress, ones that the Cypress team has no intention of fixing because they’re an integral part of how Cypress is designed.

So now that you know a little bit more about the benefits and trade-offs of using Cypress.io, you should be better equipped to decide whether or not Cypress is the best for your use case or not.

#cypressio #endtoendtesting