Cypress.io aka Selenium Killer has become the current trend in test automation. It has been able to standout from Selenium featuring better performance in many aspects. Let’s first speak on the current situation before getting in to the depth..
Before I go into this, I want to emphasize that this post is not about one particular project or any automation testers that I have worked with. I have experienced this behavior in a recent project with 10,000+ test cases.
Majority of the test automation engineers has written in selenium despite nearly everyone having a pretty grim experience due to the inherent known issues that I will state later.
Selenium tests might be difficult to write, but they are straightforward to copy and paste, which will, of course, lead to all sorts of problems.
We often hear, “If it moves, write a selenium test for it”. Automation tests must be written for the API, the frontend, the backend, the middle-end, the happy path, the sad path, the upside-down path, etc.
We won’t have any time for manual testing, how could we? We have all these flakey selenium tests to write and maintain. We are already late for this sprint, and every story must have an automation test.
After a year or so and an insanely long build, we will decide that this was a bit silly and delete them all or, worse, start again.
Why does majority use Selenium despite the problems?
- It is the industry standard, lots of online resources and a vast community to lean on
- It works across multiple OS, and multiple languages, your language and platform of choice are more than likely covered
- Cross-browser testing. Selenium supports all the major browsers so you could test on Chrome, Firefox, Safari, IE, Edge, and many more
What is the problem with Selenium?
The problems with selenium can be expressed in one word, timing.
Before we can even start writing code to assert that our test is correct, we need to ensure that whatever elements we need to interact with are visible and are in a state to accept simulated input. Remote APIs calls will need to have resolved, animations and spinners need to have concluded. The dynamic content that now makes up the majority of our apps will need to have finished rendering from the currently retrieved data of the API calls.
So what do we do while this macabre pantomime of asynchronicity is occurring? How do we stop our tests from just finishing or bottoming out because a particular text input is disabled until an API call has finished or a beautiful SVG spinner overlay has put a veil of darkness over our virtual world?
In layman’s terms, we wait for the HTML elements to be in a ready state, in selenium speak, we write many custom
waitForXXXXX code helpers. :(
One of the worst crimes to commit is to use
Thread.sleep. This is a heinous crime where a random number is plucked from thin air and used as a wild guess for when we think the UI is in a ready state. Please, never do this.
Below are my all-time favorite selenium exceptions that I have found while wading through a CI build report:
Oh hoo.. I see you smiling! You have come across these so often right..? One of the most soul-destroying moments that I have experienced is having a build fail due to a failing automation test only for it to magically pass by just rerunning the build again. This phenomenon or zombie automation test is often referred to as a flake. The main problem with the flake is that it is non-deterministic which means that a test can exhibit different behavior when executed with the same inputs at different times. You can watch the confidence in your regression test suite go up in smoke as the number of non-deterministic tests rises.
A flakey test is more than likely down to timing, latency and the macabre opera of asynchronicity that we are trying to tame with our
waitForAHero helpers that we need to keep writing to try and keep sane.
Just think how much easier this would be if we could somehow make all this asynchronous programming go away and if our world started to behave linearly or synchronously. What a natural world to test we would have. Cypress is just there to do that!
One of the main differences between cypress.io and selenium is that selenium executes in a process outside of the browser or device we are testing. Cypress executes in the browser and in the same run loop as the device under test.
Cypress will automatically wait for your application to reach this state before moving on. You are completely insulated from fussing with manual waits or retries. Cypress automatically waits for elements to exist and will never yield you stale elements that have been detached from the DOM.
Of course there are drawbacks! Still Cypress is new and developing.
- Cypress is relatively new, and it does not have the vast community that selenium does
- No cross-browser testing, this is huge and will cause less adoption until it can be cured
- There is no cross-browser support other than Chrome and Electron
When it comes to some drawbacks, the Cypress creator Brian Mann has stated that they are working on the main draw backs. So let’s give it some time huh..
Getting started with Cypress
Easiest way to install Cypress is via npm. Make sure you are done with installing Node.js on your PC.
- Open up a terminal and navigate to your desired project folder
- Enter the following command to initiate the project
3. Then enter the following command to install cypress on the project folder
npm install cypress — save-dev
This will install Cypress locally as a dev dependency for your project.
Run either of the following commands to open Cypress from the root folder of your project:
or using npx
npx cypress open
After few seconds Cypress Test Runner will open up.
Cypress has few test scripts bundled up for you to test. Try running them using the test runner and experience the difference!
We’ll meet on another article to take you deep into this tool..