Isolated Cypress UI tests
In my previous post, I described the whole test automation strategy for Spring + React application. One of the items there was isolated Cypress UI tests.
In this post, I’d like to describe what isolation means and how to achieve it using Cypress. As usual, the theory will be supported by a practical and working demo. All code on my GitHub is 100% free to use by anyone.
So what are the characteristics of an isolated test?
First of all, it needs to work offline. All external traffic should be controlled inside a test. Of course, in real-world we are connected to the network but all your isolated tests should pass in the following scenario:
- download dependencies (maven, npm, sbt…)
- run the app you test (if needed)
- disable network connection
- run tests
All tests should also be fully idempotent. They should work in any order. Each of them should set the desired application state before running.
Isolation in Cypress
Let’s look again at the system under test and analyze what isolation means for us.
We need to do two things:
stubbing incoming backend requests
asserting that outgoing frontend requests are correctly built
Cypress seems to be build-in having stubbing in mind. We only need two lines and static object to stub GET requests in cypress:
cy.server() needs to be called only once. It enables custom cy.route() stubbing for test. As you can see stubbing GET requests requires providing a response body only. Of course, you can also provide custom headers, delays, etc. Details in the command documentation.
Demo - testing data display on the front page
I assume you have successfully installed Cypress and run the first test. Cypress documentation guides you very well through the initial setup.
So let’s get started with my application tests. I usually define the most useful get stubs in custom command and run them before each test:
To define your custom commands you need to implement them:
And import in index.js file:
Optionally, for better IDE support, you may want to define this command in index.d.ts TypeScript file.
Having all that in place we can verify that our front page displays data properly:
Demo - asserting outgoing requests
When it comes to asserting that our frontend app builds and sends correct requests the flow isn’t so simple.
At first, we need to make sure that our fake backend will respond in the desired way (usually HTTP 200). The request should be tagged in .as() so we can access and verify it later.
So in a test, we would edit the existing user and override its data to the following:
We click on the first edit button, override data and save changes:
And now the clue. Here is how to assert outgoing request:
Fetch API and Cypress
Unfortunately, Cypress supports only XHR right now. Fetch support is in progress, but with no release date commitments. There is a very interesting GitHub issue where you can track work progress and read about possible workarounds.
If your application relies on Fetch API I suggest you use the following workaround:
win.fetchfor null before each test (disable it)
win.fetchwith Fetch polyfill
Your application would think that its making Fetch requests and you will be able to stub them.
Hack implementation is here:
Now you only need to import this hack in index.js:
And copy/paste fetch polyfill:
Working application with the following tests can be found here:
Let me know in comments if you like to see more Cypress posts here :)