Using Cypress for UI Test Automation
I have used Cypress as a user interface automation tool with my last two employers and have come to prefer it over other tools, even Selenium, for run-of-the-mill browser automation. My experience has been that the architectural overhead is lower since there is no emphasis on page objects, and the learning curve was a little easier to deal with.
One of the more interesting paradigms for Cypress is the concept of state. Most automation is built on an assertion—that one little thing you want to check. Everything needs to be just right for that assertion to work consistently: You need to be logged into the right account, have the right data set up, be on the right page, and have completed every dependent step your application requires.
If you try to do all of that in the context of one test, you’re probably experiencing most of the famous UI automation problems all in one go. Cypress helps solve some of this by encouraging you to carefully manage state.
The Cypress way of building a test is to build it as small as possible. You want to minimize logins via the browser, data setup through normal webpage forms, and navigation as much as possible.
I build state before the test partly through creating a test data set, and partly through the Cypress commands.js file. I use commands.js to create functions that will handle login and most of the navigation needed to get to the page I am testing. I avoid webforms as much as possible, for both speed and stability. I like to build these commands to use the API of the application I am testing, since that is less prone to performance problems or failures because something isn’t ready at the right time.
In your test, you might log in to the application once per test file, if you can get away with that, and then use the custom commands you created to set up any data that hasn’t been seeded and navigate directly to the page you want to test. Once you are on that page, you use the Cypress API directly to manipulate the page for the actual test scenario and then finally make your assertions.
The end result of this is tests that are concise. Each test is the bare minimum setup and then its assertions. These tests also seem to be more stable than most of the UI automation I have dealt with in the past, since some of the state management is done through API calls.
There are lots of options out there for UI automation, and I am not loyal to any one of them in particular. But I do enjoy the emphasis Cypress puts on not maintaining state as much as possible, as well as its simple, easy-to-learn API and low architectural overhead.
