Cypress — a genuine alternative to Selenium at last?
Mention Selenium to anyone in a software development team and the chances are you’ll provoke a reaction, ranging from a passionate defence to outright rage.
It’s fair to say that this automation tool is as contentious as they come, which is unsurprising considering the lack of viable alternatives and its subsequent widespread use over the past 10+ years.
I personally think a lot of the criticism levelled at Selenium is unfair, as people tend to blame the tool, when looking at the way it’s being utilised might be more constructive. The trend of using Selenium in conjunction with a BDD language such as Cucumber is still in full swing, and I would say that, in a lot of cases, these tests are badly designed and relied upon far too much. I’ve written about this issue before though, so I won’t cover the same ground again.
Selenium can still be a powerful end-to-end automation tool if adopted with restraint, but that’s not to say it can’t be improved upon, or complemented with something different.
Cypress is a brand new, still in private beta, test automation solution that offers a new way forward. Wholly open source, with the exception of the dashboard application, Cypress is feature rich and far more closely aligned with current development tools and practices than Selenium.
Cypress tests are written using Mocha and Chai, so the syntax and format will be familiar to most Javascript developers from the outset. The barrier to entry is therefore, virtually non-existent. It’s no exaggeration to say that, once you’ve followed the simple installation steps for the desktop application, you can have your first test running in a couple of minutes.
A basic example of a Cypress test, verifying a page title:
describe('basic navigation to Google', () => { beforeEach(() => {
cy.visit('https://google.com'); })
it('should load the Google Homepage', () => { cy.title().should('eql', 'Google'); }) })Having received early access from the helpful community of developers, I set about seeing if it lived up to its promise. Around a month ago I wrote a small test suite to run against the Red Badger website from my local machine. My focus was on the variation of scope rather than coverage, as I wanted to create a proof of concept over a suite we could rely upon. A month later though, the suite still runs with no errors, which indicates impressive stability.
One of the most appealing aspects of using Cypress is that the tests are run in your browser in real time, as you develop the test. For example, if I was to change the assertion, the test would run automatically and provide instant feedback, as is the case with a unit test. This can be extremely powerful in debugging an area of code, and also makes fixing up any tests less time consuming and infinitely less frustrating. Also, because the desktop test-runner application runs in the browser, you have full access to the developer tools to debug the output in real time. No more sifting through countless screenshots to work out where your test fell over.
Cypress tests utilise Promises to handle the asynchronous nature of Javascript, which results in a stable and user-friendly experience for those less able to work around this complication. It also removes the need for implicit wait or sleep times in your tests, as the native assertion commands have automatic waiting logic built into them. This provides a massive improvement in stability and reduction in flakiness in comparison to Selenium. I’ve yet to encounter a timeout that hasn’t pointed to a coding fault of my own.
The features of Cypress don’t end there. Built in support for mocks, spies and stubbing allow you to build out an integration test suite that removes external dependencies with ease, should you wish to. Cypress tests are fast, much faster than any other front-end automation I’ve encountered. In a CI/CD pipeline, this can be crucial in achieving a short feedback loop with each commit.
Above all else, I think Cypress could well bridge the gap between developer-driven unit tests and tester-driven front-end tests. I strongly believe the industry has a duplication and waste issue here, as the left hand is not talking to the right. By utilising the same format for each type of test, combined coverage becomes a lot clearer. Selenium may well still have a part to play in all this, as, in time, Cypress could prove to be best suited for integration tests over other applications. With the aforementioned ability to stub dependencies in an instant, and also to test individual, or groups of functions quickly and efficiently, I’ve yet to see a better integration testing tool.
If all Cypress achieves is a reduction in our reliance on Selenium for anything that’s not a unit test, I think it can be deemed a success.
Although Cypress is scheduled to be fully open-source, including the desktop application, the current roadmap suggests an as yet undisclosed fee for use of the optional dashboard application. Without knowing this cost, it’s hard to know how much of a downside this could be, or how it could affect adoption. It’s also worth noting that this is still early days for Cypress. The future promises further enhancements and patches, and hopefully, the small, dedicated community will grow exponentially.
If any of this has grabbed your interest, I urge you to apply for early access to give it a try for yourself. Also, check out this video that piqued my interest, which provides a better overview than I could ever hope to. The Kitchen Sink project is another excellent resource to better understand the full scope of what Cypress allows, so I encourage you to clone it and play with the tests at your disposal.
It’s about time we saw a step forward in the automation space. If the alternative is to stick with Selenium as your sole automation tool for the next 10 years, you have nothing to lose by trying something new.
Here at Red Badger, we’re always seeking to learn more by adopting the most cutting-edge technologies. If this sounds like something you would enjoy, check out our current vacancies, or alternatively sell your skills to us at jobs@red-badger.com.
Originally published at https://blog.red-badger.com on July 6, 2017.
