Did you know there are other open-source automation testing solutions available other than Selenium?
Well, there are, and Cypress.io is one of them.
But since my TestGuild Automation interview with Brian and Geb from Cypres.io, I’ve gotten some questions asking me to define the main differences between Cypress.io features and Selenium.
Installation of Cypress vs Selenium WebDriver
The first difference you’ll notice is that there’s no configuration needed with Cypress.
Simply install the .exe and all the drivers and dependencies are automatically installed and configured for you. This allows you to get up and running in minutes.
One of the design principles of Cypress was to be able to package and bundle everything together to make the entire end-to-end testing experience really pleasant and simple for developers.
With Selenium, you usually need to install the language binding and configure the drivers to get things to work. It’s not as straightforward.
So if quick, easy installation is a priority for you, Cypress wins for this feature.
Running Against Different Browser Vendors
With Selenium, you can run your tests against any browser. At the time of this writing, Cypress only supports Chrome.
So if running against different browser vendors is an important feature for you Selenium wins.
Cypress Runner is Open Source
Selenium and Cyprus are both open source, but Cypress also has a paid feature.
The Cypress test runner is everything that you would do on your local computer. So installing Cypress–writing and running your tests, running them headlessly or headed, changing the reporter, writing a plugin like all of those things that ultimately yields you a pass/fail–is done in the test runner and the entirety of the test runner is free and open source MIT license.
There are no restrictions.
Where the paid service comes in is when you start using their dashboard. But it's a completely optional, value-added service.
So if open source is important to you, both solutions would work for you.
The Architecture of Cypress vs. Selenium
Selenium operates by running outside the browser and executes remote commands across the network. All of the underlying commands are remote.
What you have is the test script running outside of the browser, executing remote commands into the browser. But it's never able to understand in the same run loop the reactions in the events that are being fired in the browser.
Where Selenium WebDriver runs remotely outside the browser, Cypress is the exact opposite; it runs inside the browser.
Cypress takes a different approach since it’s actually executed in the same run loop as your application. It also leverages a Node.js server to handle any task that needs to happen outside of the browser. Because of this, they claim to be able to give more consistent results since it’s able to understand everything happening inside and outside the browser.
This also affords you native access to every single object without having to deal with object serialization or over-the- wire protocols.
Basically, you pull your application into Cyprus.
As a result, it is able to synchronously be notified of every single thing that happens inside the browser. So you have native access to every single Dom element.
Cypress also makes it easy to simply drop a debugger into your application or spec code, which makes it super easy to use the developer tools while you’re developing.
How is Cypress Different from Selenium IRC?
By now you might be saying to yourself, “This sounds a lot like Selenium RC.”
Well, Yes…and No.
Obviously, Selenium RC didn't work out for myriad reasons.
Cypress is different in that it actually straddles both worlds where they run inside the browser and that enables them to do really cool things.
But sometimes you also need to expand beyond the sandbox of JavaScript.
For these instances, Cypress utilizes a lot of the same underlying browser automation APIs that Selenium WebDriver takes advantage of, but without actually using Selenium WebDriver.
It basically ends up doing the same thing, but only on a limited basis for certain types of commands.
Automation for QA or Developer
In my experience, Selenium is targeted more towards the QA developer/tester-type engineer.
Cypress is more developer-centric. It is aimed more towards making TDD development a reality with developers. But of course, Cypress can be used by any tester, not just developers.
Cypress themselves in their docs say “Our users are typically developers or QA engineers building web applications using modern JavaScript frameworks.”
For example, many Javascript developers that I've spoken with on TestTalks mention how they have tried both and end up loving Cypress.io. For example in my interview with Kent C Dodds said:
“I really am not a huge fan of Selenium. The only time that I've really spent with Selenium has all been associated with some painful memories. So Cypress was a breath of fresh air. So ever since I started or discovered Cypress about 2 years ago I think I haven't really looked at anything else. It's just such an amazing tool.”
So if you’re looking for a tool that matches up more with your testers, Selenium might be the best choice. But if they’re mostly front-end developers, you might want to also give Cypress a try.
Why Create Another Tool Instead of Using Selenium?
When Cypress.io was in the early stages of development one of the first things its founder, Brian, did was to survey a bunch of developers.
Some of the questions he asked them was, “What do you really want to see solved?” and, “What are you really struggling with?”
The responses contained an overwhelming amount of consensus about what the problems actually were.
Over and over again, he found that developers mainly struggled with writing automated tests.
They also complained that their automated tests were unreliable and too slow to use as TDD. Many also mentioned that it was pretty much the worst part of a developer’s day.
Based on that feedback, his team built Cypress to specifically target those problems and ultimately solve them.
In short, Cypress.io is a developer-focused tool that helps other developers write tests for the web.
Which Automation Tool is Right for Your Team?
Remember one automation tool is not really “better” than another.
Some teams have success with QTP, some with Selenium, some with Cypress.io — the choice is to find the tool that is best for your team. This will vary from team to team company to company.
If you have more testers than developers or use a language tech stack other than JavaScript, you should check out Selenium.
However, if your goal is to have your JavaScript developers creating TDD-type tests that also focus on UI-based automation, you might want to check out Cypress.
This article or post seems rather shallow in its comparisons. I do think Cypress.io is quite good and look forward to using it more. You keep saying “it depends” as in it may be good for your team b/c your team is unique. In the real world, teams change and morph. People quit. Get frustrated, burn out and leave for “greener pastures”, or they get downsized. That you can create faster and much more stable tests with Cypress.io is not in doubt but it also requires a steeper learning curve. Much steeper! Yet Cypress’ API does have methods for waiting…waiting longer etc. to deal with flaky tests, a symptom that is always slapped onto Webdriver tests. It takes much more time and develop robust stable tests in Webdriver than in Cypress.io I would venture to guess, but any crummy test/engineer can write up flaky tests in any tool. So oftentimes, Webdriver flaky tests are the fault of the software engineer, not the tool.
Yes, I wrote this post a while ago when I first starting hearing about Cypress.io with the intent of doing a more detailed post which I haven’t gotten around to yet. Thanks for your insights!!
Completely wrong is the statement that Cypress was made or should be used by developers rather than by QAs. Please do not post this type of information, even if it is your particular opinion.
Umm the whole point of a blog is to “have an opinion” which I clearly state in the article that it’s just my opinion, not a rule.