cypress testing methodologies
Let’s begin with a brief reminder overview of what Cypress is. In their own words, “Cypress is a next generation front end testing tool built for the modern web.” It works by launching an actual Firefox or Chromium-based browser to test your application in the same manner a human user might use it. It provides a variety of quality-of-life features including, but not limited to
- easy debugging right in the browser
- the ability to view and interact with the app at each and every step of the test
- automatic waiting so you never have to set arbitrary sleeps to allow content to load
- screenshots and videos of tests that fail
Cypress is often thought of as a replacement for End-to-End (E2E) testing tools like Selenium, however, it is also great for writing unit, integration, and user interface (UI) tests. Cypress is pretty flexible. This means that Cypress can provide a lot of value to your development process even if you already have well-established E2E tests using a tool like Selenium that you don’t want to completely rewrite.
Here at infinity interactive, we have used Cypress extensively in the context of UI tests and E2E tests. For UI tests we utilized Cypress’ built-in network spying and stubbing functionality. We can bypass the back end of the app and use mock API responses to easily test the gamut of success and error states within the UI. When we’ve used it for E2E testing we spin up both the front end and back end of the application, allowing us to test the entire app just as a user will experience it.
One recent client called us in to help them rebuild a complex guided wizard application for onboarding new clients to their product (imagine something like TurboTax). The app had an awe-inspiring variety of possible UI states dependent on the user’s information and previous steps in the guided wizard. In this case, their QA team maintained a separate Selenium repository that was used to perform E2E tests on a nightly basis against a staging environment while the developers made use of Cypress for UI tests. Utilizing Cypress in this way meant developers were able to locally test the large variety of possible UI states in smaller chunks of the larger workflow relatively quickly by using mocked API responses and pre-defined test users, bypassing the backend of the app entirely. This made for quick, easy-to-run tests that were an integral part of the development process.
For another client, one of our tasks was to build out E2E testing for a data-intensive Laboratory Inventory Management System (LIMS) application used to track a complex series of laboratory procedures, as well as the inputs and results of said procedures. The app was used in the lab on a day-to-day basis. To ensure we could thoroughly test the application and keep up with the rapid pace of development we turned, once again, to Cypress. In this E2E use case, we used Cypress to run through the entirety of the workflow while testing not only how the UI behaved, but also the integration with the backend. This allowed us to iterate and add important features while ensuring the app, which played a vital role in the day-to-day operations of the lab, remained stable regardless of the changes made. This complete suite of E2E tests ran quickly enough that developers could easily run them locally while writing code and the Continuous Integration servers could run them as code was pushed to the repository.
cypress boosts development velocity
Though it is generally thought of as more of a QA tool, one of the biggest benefits we’ve seen from Cypress over the course of our work was the significant role it played in enabling us to consistently deliver high-quality work to the clients under tight time constraints.
On our guided wizard project, the existing app already had Cypress UI tests that made use of
data-cy attributes in the HTML to find important elements on the page. Because of this, as our development team rebuilt and made drastic changes to the steps of the wizard, as long as those
data-cy attributes were carried over to the analogous versions of elements in the new design, the Cypress tests gave us confidence that the app still behaved as expected. As developers made changes, the bulk of the Cypress tests remained the same, with only minor changes needed to reflect new copy on the page or a change in the expected colors of buttons/errors/etc from the new designs. This greatly reduced the amount of time required to manually test the changes as we developed new features.
The Cypress benefits to the LIMS project were even more significant. The project was extremely fast-paced, with weekly releases to deploy new features and address user feedback. This rapid release cycle was maintained for the two years we were on the project with Cypress playing no small part in that. Because we used Cypress for E2E testing in this project we were able to make large changes with quick turnaround times to both the front and backend of the app while maintaining a high level of confidence the app continued to work as expected. About a year into the project, the business goals changed drastically, upending many of the foundational assumptions.
Our Cypress tests played a major role in allowing us to quickly pivot to meet the new business needs. The previously single-focused expected lab workflow needed to evolve and become more flexible. We needed to maintain most of the previous functionality while adding new workflows that were previously not allowed. Having a thorough suite of Cypress tests allowed us to ensure that as we made major changes to the foundations of the app we still maintained backward compatibility with the original workflow at the time of development rather than during the QA process, or worse, in production. With Cypress integrated into our CI pipeline, our developers were able to see that our tests passed before they looked at any change, which allowed them to be efficient in their review, and get the PRs approved more quickly. By running the Cypress tests during development, there was almost no need for our developers to run through the workflow by hand thanks to the ability to interact with the actual app inside the Cypress test runner.
cypress frees up QA resources
The benefits of making Cypress tests part of the development process also spill over into benefits for QA teams. Cypress tests take a lot of the burden of regression testing away from manual QA. As mentioned earlier, this has the benefit of allowing development teams to safely move a lot more quickly and also gives QA teams more time to test new features more thoroughly. On the LIMS project, a series of regression tests on various permutations of the workflow might take hours by hand, but with Cypress, we can accomplish this in seconds. Writing Cypress tests to check for error states in form submissions and other common errors users might experience is a trivial task, taking the mundane repetitive tasks off of the QA team, and freeing them up for finding more obscure and interesting ways to break the app.
We also noticed fewer cycles of back and forth between QA and development due to bugs thanks to Cypress tests catching a majority of bugs before they made it up to a staging environment. This reduced the amount of time the QA team needed to write up bug tickets for fairly standard bugs. This, in turn, enabled QA to focus their time on more significant pre-release tasks before features were deployed to production.
We’ve found Cypress tests, whether UI or E2E, to be an extremely valuable part of the development process. A small investment of time that can pay off with big rewards. The benefits to developers, QA, and especially end users are significant. Cypress tests make for more agile teams that can release important features quicker and safer than without.
want to know more?
There’s a lot to talk about with Cypress and testing automation—and how it can positively impact your business. We’ve worked with clients for over 25 years on the best ways to effectively leverage technology. Get in touch, and we’d be happy to chat with you about the problems you’re trying to solve.