E2E Testing with Cypress -05- Trade-offs In Cypress

Key Differences

Key differences with other testing frameworks

• Cypress does not use Selenium

• Cypress tests are only written in JavaScript

• Cypress is all in one

These architectural improvements unlock the ability to do TDD with full e2e tests. You can develop faster while driving the entire dev process with tests because: you can see your application; you still have access to the developer tools, and changes are reflected in real-time. The end result is that you will have developed more, your code will be better, and it will be completely tested. If you opt for parallelization and automated load balancing will further supercharge your test speeds.

But, there are some serious downsides to these architectural changes.

The following permanent and temporary trade-offs are well discussed in Cypress documentation. Please follow the official documentation for more information. I've just listed out the main point just for an overview.

Permanent trade-offs

• Automation Restrictions: Cypress is a specialized tool that does one thing really well: end-to-end testing of web applications while they are under development. You should not use Cypress for things it is not designed for such as: - Indexing the web - Spidering links - Performance testing - Scripting 3rd party sites There are other excellent tools that are optimized for doing each item listed above.
• Inside the browser: In case you missed it before - Cypress tests run inside of the browser! It makes it a little bit harder to communicate with the back end - like your server or database. You will not be able to connect or import those server-side libraries or modules directly.
• Multiple Tabs: It will never have multi-tabs support.
• Multiple browsers open at the same time: You cannot use Cypress to drive two browsers at the same time.
• Same Origin: Each test is limited to only visiting domains that are determined to be of the same-origin. What is same-origin? Two URLs have the same origin if the protocol, port(if specified), and host are the same for both. Cypress automatically handles hosts of the same superdomain by injecting `document.domain` into `text/html` pages, so a host of the same super domains considered fine.

Temporary trade-offs

IMO Cypress has a pretty responsive issues section on GitHub. Many issues that are being worked on are:

• Lack of a cy.hover() command.
• There is no cy.tab() command.
• There is not any native or mobile event support.
• Testing file uploads is application-specific.
• Testing file downloads is application-specific.
• Iframe support is somewhat limited but does work.
• You cannot use cy.route() on window.fetch.

Problems I faced with my project's tests

• Cypress says, the browser XHRs are properly tracked, and we can wait for them too. But it is not true for me. The test-runner does not log about the XHR requests triggered by the browser interaction, and I cannot wait dynamically for some time-consuming requests.

• Testing inside iframes? Well, it's gonna bother you. I am working on a project which uses iframes with large contents and takes some time to load properly. Following the documentation and cypress blogs were also not quite helpful. For now, I'm using static wait before diving inside any iframes. If somebody has a better idea, well, please share!

• I feel like why we choose Cypress while testing dropdown fields 😂. I find most of the official tips for dropdown testing is with <select>...</select>. But the recent web is mostly based on frameworks like VueJs, ReactJs, etc. which uses a different mechanism to render dropdowns (using classes rather than using select tag). Options are extracted from some API requests and may also have abilities like autocompletion. With these features included the browser elements keeps on changing (some get in, and some are removed out completely). Running tests with such form fields interactions, you'll surely encounter the Element is detached from the DOM error ref. I suggest do-not-get-too-detached blog to handle this type of errors.

• Test just terminates when it likes: Only half of the test runs and that particular test is marked as passed by cypress (happens sometimes but can litter test result accuracy)

What's Next 😎?

Cool, we've known some errors that we may encounter while testing with Cypress. Some are permanent and some are temporary. Some can be handled with ninja-techniques 🐱‍💻. So please choose your testing framework according to your project's need. Thank you!

Enough with these testing tips. Now we want tests running on some CI 🔌 and be always verified with our product services ✅. In the next part of the series, we'll see the CI/CD part of e2e testing with Cypress.

Your thoughts, comments, or questions about e2e testing with cypress are always welcome. Happy Coding 🎉