I asked some developer friends a while back about whether people still like Watir for testing or if people are going more wholesale down the Selenium route. Their answer: “None of the above, try Cypress instead.”
I love it when I ask a question and get an answer completely out of left field. Turns out they were absolutely right. Cypress has proved to be excellent. It makes writing browser automation tests fun. There was a bit of a learning curve, and so I want to share two things that it took a while for me to wrap my head around:
- Understanding Cypress’s async nature, and the need to rely on
thenfor certain use cases. - Understanding that if you follow along the tests in the UI then what you see isn’t always what Cypress sees.
To illustrate this, see this gist that accesess localStorage under different circumstances:
The first thing to note here is that Cypress’s async nature means that, for example, accessing localStorage makes sense from inside a then or inside an afterEach, but not from inside the main body of the test. See below log results from the first two tests in the gists which [a] open a page and clicks a link in it and [b] directly opens the same page.
You can see that the logging from the main body of the test doesn’t produce any output (row 7 from the first test and 4 from the second test).
The second thing to note is that what is seen is not always what is real.
In the third test, when following along with dev tools, I could see that localStorage was being set, but even the afterEach claimed there was no localStorage set (see row 1 of the afterEach).
I suspect this is because when an interactive user goes to https://docs.cypress.io, they end up redirected to a different page, and localStorage gets set during this redirection. What you are seeing in Dev tools is what is set as part of the redirection process (see how the URL in the image above is different to the one the test lands on), but what Cypress reports is what it found prior to the redirection.
Be good, work hard, get lucky 