Key Differences between Cypress and Other Testing Frameworks

In the previous tutorial we gave you the general overview of Cypress, what it is and why you should use it, we also introduced you to some of its features, the tutorial you are about to read will we outline the key differences between Cypress and other testing frameworks.

Architecture

When you test with Cypress, it will be executed inside your browser. This is opposite the convention adopted by most testing tools (such as Selenium) which operate by running outside of the browser and then executing remote commands across the network.

There is a Node server process behind Cypress. This Node process and Cypress constantly communicate, synchronize and perform tasks on behalf of each other. Since you have access to both parts (Node and Cypress), it enables you to easily respond to your application’s event in real time, it is also able to work outside of the browser for tasks that need a higher privilege.

In order to read and alter web traffic on the fly, Cypress also operates at the network layer.

This configuration enables Cypress to not only modify everything coming in and out of the browser, but to also change code that may affect its ability to automate the browser.

Hence, Cypress has control of the entire automation process from top to bottom, this puts it in a good position of being able to understand everything that is happening in and out of the browser.

This implies that Cypress is capable of delivering test results that are more consistent than any testing tool.

Additionally, since Cypress is installed locally on your machine, it can tap into your operating system for automation tasks. This enables you to be able to perform tasks like: taking screenshots, recording video, general file system operations and network operations possible.

Native access

Earlier we told you that Cypress operates within your application, this architecture grants Cypress native access to every single object. Whether it is the window, the document, a DOM element, an instance of your application, a function, a timer, a service worker or anything else. You have access to all of them when running your Cypress tests. An object serialization does not exist, there is also no over-the-wire protocol, you have all the native access. Your test code has access to all the same objects that your application has access to.

New kind of testing

Since you have control over your application, this control exposes you to a new way of testing that has never been possible before. Currently Cypress enables you to alter any aspect of how your application works, this is in contrast to ‘locked out’ and not being able to easily control your application.

Cypress enables you to create fast tests in much the same way you can in a unit test. For example, you can:

• Stub the browser or your application’s functions and force them to suit your test case needs.
• Expose data stores so that you can alter the state of your application from you code directly.

And much more.

Shortcuts

You really don’t have to interact with the UI all the time, in order to bypass some actions, Cypress provides you with shortcuts, these shortcuts prevents you from being forced to always ‘act like a user’. You can use commands like cy.request() to send HTTP requests directly so that you can programmatically log in. Cookies are sent back to you automatically; this process completely bypasses CORS. This gives you the power of choice to decide when to test like a user and when to skip repetitive and slow parts.

Flake resistant

Cypress has both knowledge and understanding of everything that happens in your application synchronously. It gets notified during page load and unloads. Cypress knows exactly how fast an element is animating and waits for it to stop animating on specific network requests to finish.

Most Cypress commands are executed in the browser; this ensures that there is no network lag. You will have to use assertions to tell Cypress what the desired state of your application should be when working with modern JavaScript frameworks with complex UI’s.

Cypress also insulates you from fussing with manual waits or retries. It waits for elements to exist and will never supply stale elements that have been detached from the DOM to you.

Debuggability

With Cypress you have hundreds of custom error messages that describe the exact reason that Cypress failed your test.

Additionally, Cypress will take screenshot of your application, thus enabling you to time travel back to the state it was when the commands ran.

You can use the Developer Tools while your tests run, you will be able to see every console message as well as network requests.

Trade offs

Although Cypress comes fully baked with a lot of features and capabilities there are important tradeoffs that you should be aware of. Here are some of the permanent tradeoffs of Cypress:

Permanent trade-offs:

• Cypress is not to be considered a general purpose automation tool.
• Cypress commands are run inside of a browser.
• There will never provide support for multiple browser tabs.
• You will not be able to use Cypress to drive two browsers at the same time.
• Every Cypress test is bound to a single origin.