DEV Community

Ben Halpern for The DEV Team

Posted on

Cypress vs.....

Hey folks, we're considering adopting Cypress for E2E testing on DEV, but want to get some feedback if anyone wants to propose other tools in this genre.

We currently do some E2E in rspec (Rails), but it's also a component of the app and process which is under-developed.

So feedback is much appreciated, thanks a lot!

Latest comments (47)

Collapse
 
johnbwoodruff profile image
John Woodruff

We switched to Cypress from Angular's Protractor and have absolutely loved it. It's modern, easy to use, and seems much more stable and less prone to random failures. (just in our experience of course) While there are some trade-offs, we personally didn't see those as deal breakers for our use case, and every testing framework you use is going to be that way.

Collapse
 
davidz profile image
David🦉

We do use Cypress in my workplace and we're pretty happy with it. Even though you can still find some limitations compared to other more mature tools, its benefits widely compensate the small losses you may find.

Collapse
 
scriptmunkee profile image
Ken Simeon

I agree with @shiling, that you have decide what you're trying to accomplish overall. There is nothing wrong with RSpec and your current use to validate your base Rails infrastructure [ yes, I took a quick peak ].

I can only guess that you're looking to expand your functional testing coverage with UI based testing [ not truly E2E testing ]. Its definitely helpful for when you're changing foundational underlining code that shouldn't impact the user experience or UI components. However, as its been pointed out the intentions of the UI testing needs to be defined.

Now I can't give you insight into Cypress vs TestCafe, but I can give you my thoughts or insights for adopting GUI automation from a QE perspective.

  • If the UI test creation audience is the developers and not a QE, then keep the test framework & language close to the daily used language(s) (easier adoption)

  • Be definitive about separating automated test focus [unit tests, API tests & functional UI tests].

  • UI test should validate/assert behavior and/or data interactions.

  • Treat UI tests like a unit test. They should run independently. They should not rely on another tests success or failure.

  • When UI tests are independent, all necessary data to complete a test must be seeded, created or found in the test environment [ key for a successful CI/CD/CT environment ].

  • True UI E2E tests should only be built in special cases and run during integration or before a release.

Collapse
 
vikmy profile image
vikmy • Edited

For me it's Test cafe because of it being browser agnostic. You can have a look at surveyjs github on how test cafe is being used

Collapse
 
swarupkm profile image
Swarup Kumar Mahapatra • Edited

Capybara with Ruby 😍
Cucumber as test framework.

Collapse
 
timdeschryver profile image
Tim Deschryver

Make sure to check out Cypress Testing Library for some useful commands.

The @testing-library family of packages helps you test UI components in a user-centric way.

The more your tests resemble the way your software is used, the more confidence they can give you.

Collapse
 
shiling profile image
Shi Ling • Edited

🧐What's wrong with your current experience with rspec?

I could really go on about the pros and cons of different testing tools, but without knowing what's currently not working out for your team makes it hard to recommend something suitable for your requirements and preferences - because there's always a trade off when you pick a tool. 🙃

Before switching tools, I usually think care about what exactly do I want in my new tool. I try to resist jumping on to a bandwagon simple because it's popular. I knew what I disliked about Angular - it was hard to teach to junior devs - and picked Vue instead of the more popular React back in 2016. And recently, it turns out I didn't really like Elastic + Kibana for analytics because I want more flexibility with structuring data, so I'm trying out MongoDB Altas instead.

Figure out the following first:

Requirements:

  • What browsers do you want to test for now? Cypress and Puppeteer only supports Chrome.

Commitment level:

  • How much time does your team want to commit to creating and maintaining the tests? Selenium requires a lot of commitment to learn to write and setup and maintain the infrastructure.
  • Do you have time to commit to setting up pipelines to ensure tests are automatically ran? Tests that are run manually will certainly be forgotten - it's important to make sure they run automatically. Nearly all FOSS testing tools will require you to DIY integration with CI/CD. Most paid tools will offer built-in Scheduling and Monitoring capabilities.

Preference:

  • Does your team prefer BDD-style?
  • Does your team want the tests to live beside UI code in Ruby on Rails? Cabybara + RSpec is the popular choice. If your team is comfortable with Javascript, there's a lot of variety to pick from.

Other factors to consider:

  • How fast do you want the tests to run? Cypress is pretty damn fast, so is Puppeteer. I believe both of them utilises the Chrome DevTools Protocol instead of WebDriver protocol which makes it fast, but you'll lose some accuracy in terms of simulating actual interactions instead of syntactic interactions.
  • Do you want screenshots for every test and every step? Most tools require you to manually add steps to capture screenshots.
  • Do you want visual testing?

While @picocreator and I are the creators of UI-licious ourselves, we won't recommend it if it doesn't suit your style. :) It's designed to be easy for non-technical folks, whilst flexible for Javascript programmers, and supports all browsers - but some folks don't like Javascript, others want tests to run blazing fast, and plenty of folks want it free. ¯_(ツ)_/¯

Collapse
 
shiling profile image
Shi Ling • Edited

To add on, I've seen a lot of migration projects (for front-end, back-end, testing-frameworks) fail because the problem was the process and team capabilities/capacity, not the tools. I think it's important to really visualise the ideal workflow for the team, and then find the tool that fits. Finding the tool first and then fitting the team to the tool is like chopping the foot to fit the shoe (which is why I'm usually wary of overly-opinionated tools).

Collapse
 
flictuum profile image
Florent Bertrand

Thank you for your share, it really helped me to choose my testing tools ! I agree with you the first thing to do is to define what the team can do ...

Collapse
 
angrykoala profile image
angrykoala • Edited

While facing a similar situation and trying several tools, I ended up making github.com/angrykoala/wendigo with the intention of making frontend+e2e tests as simple as possible

It is basically a wrapper of Puppeteer (with all the goodness and bad of Puppeteer), it's syntax is similar to what you would find with cypress but way less opinionated over how to write your tests and what other tools you may use (which is the main downside I found with Cypress). Not sure if it may help you but you may want to give it a look as an alternative

Collapse
 
destro_mas profile image
Shahjada Talukdar • Edited

I gave a Talk about Cypress in Berlin, Germany. Please have a look. It has slides but not the code samples of demo.

Collapse
 
destro_mas profile image
Shahjada Talukdar

I like cypress.
The code is pure js and looks very native to me.
Developer experience is cool and so easy to use.

Collapse
 
andrewbrown profile image
Andrew Brown 🇨🇦 • Edited

I guess the question is what is the gain? Convenience?

Doesn't a Selenium-based driver ensure you can test cross-browser and since this is an open-source platform where we need to be inclusive to browser and platform choice that we'd choose Selenium which is going to give us that coverage?

Is Capyabara + Cucumber really that bad? How slow would it really be? I have a project with 40 features and it takes 1-2mins to run.

I would say before introducing and E2E tool into the codebase we get specs moved to where Rails developers expect them to be. I have little problem working with the codebase quirks but let's ease it for juniors.

Collapse
 
swarupkm profile image
Swarup Kumar Mahapatra

Capybara + cucumber. In a selenium grid docker setup.
Parallel_cucumber to parallelize the tests .
Thats 😍 for me.
I have run 420 tests accross 20 parallel threads , and complete tests under 30 minutes

Collapse
 
aghost7 profile image
Jonathan Boudreau

My main issue with cypress is that it only supports Chrome. For me this is a deal breaker.

Collapse
 
kbuechner profile image
Katherine Buechner

I believe ie11 is on the roadmap, but that may not be the browser you're looking for

Collapse
 
erezcohen profile image
Erez Cohen

Seems like the addition of FF and Edge is even closer: github.com/cypress-io/cypress/issu...

Collapse
 
arturoaviles profile image
Arturo Avilés

If you need to test iframes, selenium is the best option to work with 👍🏼 I have tried using Cypress, Katalon Studio, etc. but I got stuck because they weren't compatible with iframes in some way or another. Maybe an option would be to use Puppeteer but it only uses Chrome.

Collapse
 
cristinasolana profile image
Cristina Solana

I used Cypress on a project and loved it, but I have a hard time selling it to stakeholders because it isn't cross browser.

Chrome is rarely the browser with weird bugs so testing there is considered happy path. :/

Collapse
 
shiling profile image
Shi Ling

Chrome is rarely the browser with weird bugs so testing there is considered happy path. :/

So true, since most developers use Chrome as their main dev and debugging browser - of course it looks perfect - it's a classic "it works on my machine", except replace "machine" with "browser".

I'm pretty guilty of this tendency as well. I hope to see Firefox and Edge catch up to offer a better experience for developers.

Collapse
 
cristinasolana profile image
Cristina Solana

Precisely, if I have to test manually on all supported browsers, it would be counterproductive.

Off topic, but I like Firefox Devtools and they're adding some nice new features like letting you know when css props is not having any effect, but I am very used to the Chrome experience so hard to change. :P

Collapse
 
elmuerte profile image
Michiel Hendriks

What is Firefox missing for developers?

Thread Thread
 
shiling profile image
Shi Ling

I tried to switch to FF twice this year, but while the dev tools is great, performance is noticably slower compared to Chrome on many websites.

Also, ReCaptcha is so nasty on non-Chrome browsers, I spent 5 minutes solving a challenge and still I was getting more puzzles (it's not FF's fault, Google's ReCaptcha is just so fucked up).

Thread Thread
 
elmuerte profile image
Michiel Hendriks

ReCaptcha is so nasty on non-Chrome browsers, I spent 5 minutes solving a challenge and still I was getting more puzzles

That is a privacy price I'm willing to pay.

I can't comment on performance. I have been using Firefox since 0.4. I only use chrome when needed to verify non-standard webstuff. Firefox never felt slow to me.

Thread Thread
 
shiling profile image
Shi Ling

Haha yeah... I'm spoiled by Chrome now - but these days either Chrome is slowing down or websites are getting fatter... - I might jump in to migrate to FF again.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.