Alternatives to Cypress logo

Alternatives to Cypress

Selenium, TestCafe, Puppeteer, WebdriverIO, and Jest are the most popular alternatives and competitors to Cypress.
2.4K
2K
+ 1
115

What is Cypress and what are its top alternatives?

Cypress is a popular open-source automation testing tool known for its fast and reliable test execution capabilities. It offers features like automatic waiting, real-time reloads, and easy debugging, making it a preferred choice for many developers. However, Cypress has limitations such as lack of support for multiple browser testing and limited support for testing mobile applications.

  1. Selenium: Selenium is a widely used open-source automation testing tool that supports various programming languages and browsers. It provides robust test automation capabilities and is suitable for large-scale projects. However, setting up Selenium can be complex compared to Cypress.
  2. Katalon Studio: Katalon Studio is an all-in-one automation testing tool that integrates various testing frameworks and tools. It offers a user-friendly interface and supports web, API, and mobile testing. One downside is that some advanced features are available only in the paid version.
  3. TestComplete: TestComplete is a comprehensive automation testing tool that supports desktop, web, and mobile applications. It offers features like scriptless test creation and robust object recognition, but it can be expensive for small teams.
  4. Protractor: Protractor is an end-to-end test framework specifically designed for Angular applications. It uses WebDriverJS to automate tests on AngularJS applications and provides built-in support for Angular-specific locators. However, Protractor may not be suitable for non-Angular applications.
  5. TestCafe: TestCafe is a modern open-source automation testing tool that allows testing web applications without WebDriver. It offers features like automatic waiting and built-in parallel testing, but it lacks support for mobile testing.
  6. Robot Framework: Robot Framework is a generic test automation framework for acceptance testing and acceptance test-driven development. It supports keyword-driven test automation and enables easy integration with other tools and libraries. However, its learning curve may be steep for beginners.
  7. Jest: Jest is a delightful JavaScript testing framework with a focus on simplicity and speed. It is suitable for unit testing and offers features like snapshot testing and code coverage analysis. However, Jest is primarily designed for unit testing and may not be suitable for end-to-end testing like Cypress.
  8. Nightwatch.js: Nightwatch.js is an automated testing framework for web applications and websites. It supports end-to-end testing using a simple and powerful API. However, Nightwatch.js may have a steeper learning curve compared to Cypress.
  9. Playwright: Playwright is a tool for automating browsers that provides fast, reliable, and capable automation for modern web apps. It supports multiple browsers and devices, and offers powerful automation features. However, Playwright is relatively new compared to Cypress, and its ecosystem may still be evolving.
  10. Puppeteer: Puppeteer is a Node library which provides a high-level API over the Chrome DevTools Protocol. It is suitable for controlling headless Chrome or Chromium over the DevTools protocol, and offers features like taking screenshots and generating PDFs. However, Puppeteer is more low-level compared to Cypress and may require more advanced programming skills.

Top Alternatives to Cypress

  • Selenium
    Selenium

    Selenium automates browsers. That's it! What you do with that power is entirely up to you. Primarily, it is for automating web applications for testing purposes, but is certainly not limited to just that. Boring web-based administration tasks can (and should!) also be automated as well. ...

  • TestCafe
    TestCafe

    It is a pure node.js end-to-end solution for testing web apps. It takes care of all the stages: starting browsers, running tests, gathering test results and generating reports. ...

  • Puppeteer
    Puppeteer

    Puppeteer is a Node library which provides a high-level API to control headless Chrome over the DevTools Protocol. It can also be configured to use full (non-headless) Chrome. ...

  • WebdriverIO
    WebdriverIO

    WebdriverIO lets you control a browser or a mobile application with just a few lines of code. Your test code will look simple, concise and easy to read. ...

  • Jest
    Jest

    Jest provides you with multiple layers on top of Jasmine.

  • Protractor
    Protractor

    Protractor is an end-to-end test framework for Angular and AngularJS applications. Protractor runs tests against your application running in a real browser, interacting with it as a user would. ...

  • Juniper
    Juniper

    It provides high-performance networking & cybersecurity solutions to service providers, enterprise companies & public sector organizations. ...

  • Git
    Git

    Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. ...

Cypress alternatives & related posts

Selenium logo

Selenium

15.6K
527
Web Browser Automation
15.6K
527
PROS OF SELENIUM
  • 177
    Automates browsers
  • 154
    Testing
  • 101
    Essential tool for running test automation
  • 24
    Record-Playback
  • 24
    Remote Control
  • 8
    Data crawling
  • 7
    Supports end to end testing
  • 6
    Easy set up
  • 6
    Functional testing
  • 4
    The Most flexible monitoring system
  • 3
    End to End Testing
  • 3
    Easy to integrate with build tools
  • 2
    Comparing the performance selenium is faster than jasm
  • 2
    Record and playback
  • 2
    Compatible with Python
  • 2
    Easy to scale
  • 2
    Integration Tests
  • 0
    Integrated into Selenium-Jupiter framework
CONS OF SELENIUM
  • 8
    Flaky tests
  • 4
    Slow as needs to make browser (even with no gui)
  • 2
    Update browser drivers

related Selenium posts

Kamil Kowalski
Lead Architect at Fresha · | 28 upvotes · 4.1M views

When you think about test automation, it’s crucial to make it everyone’s responsibility (not just QA Engineers'). We started with Selenium and Java, but with our platform revolving around Ruby, Elixir and JavaScript, QA Engineers were left alone to automate tests. Cypress was the answer, as we could switch to JS and simply involve more people from day one. There's a downside too, as it meant testing on Chrome only, but that was "good enough" for us + if really needed we can always cover some specific cases in a different way.

See more
Benjamin Poon
QA Manager - Engineering at HBC Digital · | 8 upvotes · 2.2M views

For our digital QA organization to support a complex hybrid monolith/microservice architecture, our team took on the lofty goal of building out a commonized UI test automation framework. One of the primary requisites included a technical minimalist threshold such that an engineer or analyst with fundamental knowledge of JavaScript could automate their tests with greater ease. Just to list a few: - Nightwatchjs - Selenium - Cucumber - GitHub - Go.CD - Docker - ExpressJS - React - PostgreSQL

With this structure, we're able to combine the automation efforts of each team member into a centralized repository while also providing new relevant metrics to business owners.

See more
TestCafe logo

TestCafe

194
26
A Node.js tool to automate end-to-end web testing
194
26
PROS OF TESTCAFE
  • 8
    Cross-browser testing
  • 4
    Open source
  • 4
    Easy setup/installation
  • 4
    Built in waits
  • 3
    UI End to End testing
  • 2
    Supports Devices without extra software/package
  • 1
    Both client and server side debug
CONS OF TESTCAFE
  • 9
    No longer free

related TestCafe posts

What tools will be a good fit for the AngularJS application? I am experienced in Selenium WebDriver with Java. Any suggestion for Selenium or TestCafe?

See more
Puppeteer logo

Puppeteer

643
26
Headless Chrome Node API
643
26
PROS OF PUPPETEER
  • 10
    Very well documented
  • 10
    Scriptable web browser
  • 6
    Promise based
CONS OF PUPPETEER
  • 10
    Chrome only

related Puppeteer posts

Raziel Alron
Automation Engineer at Tipalti · | 7 upvotes · 2M views

Currently, we are using Protractor in our project. Since Protractor isn't updated anymore, we are looking for a new tool. The strongest suggestions are WebdriverIO or Puppeteer. Please help me figure out what tool would make the transition fastest and easiest. Please note that Protractor uses its own locator system, and we want the switch to be as simple as possible. Thank you!

See more

I work in a company building web apps with AngularJS. I started using Selenium for tests automation, as I am more familiar with Python. However, I found some difficulties, like the impossibility of using IDs and fixed lists of classes, ending up with using xpaths most, which unfortunately could change with fixes and modifications in the code.

So, I started using Puppeteer, but I am still learning. It seems easier to find elements on the webpage, even if the creation and managing of arrays of elements seem to be a little bit more complicated than in Selenium, but it could be also due to my poor knowledge of JavaScript.

Any comments on this comparison and also on comparisons with similar tools are welcome! :)

See more
WebdriverIO logo

WebdriverIO

348
40
Webdriver/Selenium 2.0 JavaScript bindings for Node.js
348
40
PROS OF WEBDRIVERIO
  • 11
    Various integrations to vendors like Sauce Labs
  • 10
    Open Source
  • 8
    Great community
  • 7
    Easy to setup
  • 4
    Best solution for broad browser support
CONS OF WEBDRIVERIO
  • 8
    High maintenance

related WebdriverIO posts

Raziel Alron
Automation Engineer at Tipalti · | 7 upvotes · 2M views

Currently, we are using Protractor in our project. Since Protractor isn't updated anymore, we are looking for a new tool. The strongest suggestions are WebdriverIO or Puppeteer. Please help me figure out what tool would make the transition fastest and easiest. Please note that Protractor uses its own locator system, and we want the switch to be as simple as possible. Thank you!

See more
Kevin Roulleau
QA Engineer Freelance at happn · | 5 upvotes · 1.2M views

I chose WebdriverIO and Appium to implement a E2E tests solution on a native mobile app. WebdriverIO goes well beyond just implementing the Selenium / Appium protocol and allows to run tests in parallel out of the box. Appium has the big advantage of supporting iOS and Android platforms, so the test codebase and tools are exactly the same, which greatly reduces the learning curve and implementation time.

See more
Jest logo

Jest

9.7K
175
Painless JavaScript Unit Testing
9.7K
175
PROS OF JEST
  • 36
    Open source
  • 32
    Mock by default makes testing much simpler
  • 23
    Testing React Native Apps
  • 20
    Parallel test running
  • 16
    Fast
  • 13
    Bundled with JSDOM to enable DOM testing
  • 8
    Mock by default screws up your classes, breaking tests
  • 7
    Out of the box code coverage
  • 7
    Promise support
  • 6
    One stop shop for unit testing
  • 3
    Great documentation
  • 2
    Assert Library Included
  • 1
    Built in watch option with interactive filtering menu
  • 1
    Preset support
  • 0
    Can be used for BDD
  • 0
    Karma
CONS OF JEST
  • 4
    Documentation
  • 4
    Ambiguous configuration
  • 3
    Difficult
  • 2
    Many bugs still not fixed months/years after reporting
  • 2
    Multiple error messages for same error
  • 2
    Difficult to run single test/describe/file
  • 2
    Ambiguous
  • 2
    Bugged
  • 1
    BeforeAll timing out makes all passing tests fail
  • 1
    Slow
  • 1
    Reporter is too general
  • 1
    Unstable
  • 1
    Bad docs
  • 1
    Still does't support .mjs files natively
  • 1
    Can't fail beforeAll to abort tests
  • 0
    Interaction with watch mode on terminal

related Jest posts

Simon Reymann
Senior Fullstack Developer at QUANTUSflow Software GmbH · | 24 upvotes · 4.9M views

Our whole Vue.js frontend stack (incl. SSR) consists of the following tools:

  • Nuxt.js consisting of Vue CLI, Vue Router, vuex, Webpack and Sass (Bundler for HTML5, CSS 3), Babel (Transpiler for JavaScript),
  • Vue Styleguidist as our style guide and pool of developed Vue.js components
  • Vuetify as Material Component Framework (for fast app development)
  • TypeScript as programming language
  • Apollo / GraphQL (incl. GraphiQL) for data access layer (https://apollo.vuejs.org/)
  • ESLint, TSLint and Prettier for coding style and code analyzes
  • Jest as testing framework
  • Google Fonts and Font Awesome for typography and icon toolkit
  • NativeScript-Vue for mobile development

The main reason we have chosen Vue.js over React and AngularJS is related to the following artifacts:

  • Empowered HTML. Vue.js has many similar approaches with Angular. This helps to optimize HTML blocks handling with the use of different components.
  • Detailed documentation. Vue.js has very good documentation which can fasten learning curve for developers.
  • Adaptability. It provides a rapid switching period from other frameworks. It has similarities with Angular and React in terms of design and architecture.
  • Awesome integration. Vue.js can be used for both building single-page applications and more difficult web interfaces of apps. Smaller interactive parts can be easily integrated into the existing infrastructure with no negative effect on the entire system.
  • Large scaling. Vue.js can help to develop pretty large reusable templates.
  • Tiny size. Vue.js weights around 20KB keeping its speed and flexibility. It allows reaching much better performance in comparison to other frameworks.
See more

I'm working as one of the engineering leads in RunaHR. As our platform is a Saas, we thought It'd be good to have an API (We chose Ruby and Rails for this) and a SPA (built with React and Redux ) connected. We started the SPA with Create React App since It's pretty easy to start.

We use Jest as the testing framework and react-testing-library to test React components. In Rails we make tests using RSpec.

Our main database is PostgreSQL, but we also use MongoDB to store some type of data. We started to use Redis  for cache and other time sensitive operations.

We have a couple of extra projects: One is an Employee app built with React Native and the other is an internal back office dashboard built with Next.js for the client and Python in the backend side.

Since we have different frontend apps we have found useful to have Bit to document visual components and utils in JavaScript.

See more
Protractor logo

Protractor

1K
33
End-to-end test framework for Angular and AngularJS applications
1K
33
PROS OF PROTRACTOR
  • 9
    Easy setup
  • 8
    Quick tests implementation
  • 6
    Flexible
  • 5
    Open source
  • 5
    Promise support
CONS OF PROTRACTOR
  • 4
    Limited

related Protractor posts

Raziel Alron
Automation Engineer at Tipalti · | 7 upvotes · 2M views

Currently, we are using Protractor in our project. Since Protractor isn't updated anymore, we are looking for a new tool. The strongest suggestions are WebdriverIO or Puppeteer. Please help me figure out what tool would make the transition fastest and easiest. Please note that Protractor uses its own locator system, and we want the switch to be as simple as possible. Thank you!

See more
Sai Chaitanya Mankala
Tech Lead at KIOT Innovations · | 6 upvotes · 874.1K views

Protractor or Cypress for ionic-angular?

We have a huge ionic-angular app with almost 100 pages and 10+ injectables. There are no tests written yet. Before we start, we need some suggestions about the framework. Would you suggest Cypress or Angular's Protractor with Jasmine / Karma for a heavy ionic app with Angular?

See more
Juniper logo

Juniper

21
0
High-performance networking & cybersecurity solutions
21
0
PROS OF JUNIPER
    Be the first to leave a pro
    CONS OF JUNIPER
      Be the first to leave a con

      related Juniper posts

      Git logo

      Git

      297.5K
      6.6K
      Fast, scalable, distributed revision control system
      297.5K
      6.6K
      PROS OF GIT
      • 1.4K
        Distributed version control system
      • 1.1K
        Efficient branching and merging
      • 959
        Fast
      • 845
        Open source
      • 726
        Better than svn
      • 368
        Great command-line application
      • 306
        Simple
      • 291
        Free
      • 232
        Easy to use
      • 222
        Does not require server
      • 27
        Distributed
      • 22
        Small & Fast
      • 18
        Feature based workflow
      • 15
        Staging Area
      • 13
        Most wide-spread VSC
      • 11
        Role-based codelines
      • 11
        Disposable Experimentation
      • 7
        Frictionless Context Switching
      • 6
        Data Assurance
      • 5
        Efficient
      • 4
        Just awesome
      • 3
        Github integration
      • 3
        Easy branching and merging
      • 2
        Compatible
      • 2
        Flexible
      • 2
        Possible to lose history and commits
      • 1
        Rebase supported natively; reflog; access to plumbing
      • 1
        Light
      • 1
        Team Integration
      • 1
        Fast, scalable, distributed revision control system
      • 1
        Easy
      • 1
        Flexible, easy, Safe, and fast
      • 1
        CLI is great, but the GUI tools are awesome
      • 1
        It's what you do
      • 0
        Phinx
      CONS OF GIT
      • 16
        Hard to learn
      • 11
        Inconsistent command line interface
      • 9
        Easy to lose uncommitted work
      • 8
        Worst documentation ever possibly made
      • 5
        Awful merge handling
      • 3
        Unexistent preventive security flows
      • 3
        Rebase hell
      • 2
        Ironically even die-hard supporters screw up badly
      • 2
        When --force is disabled, cannot rebase
      • 1
        Doesn't scale for big data

      related Git posts

      Simon Reymann
      Senior Fullstack Developer at QUANTUSflow Software GmbH · | 30 upvotes · 11.2M views

      Our whole DevOps stack consists of the following tools:

      • GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
      • Respectively Git as revision control system
      • SourceTree as Git GUI
      • Visual Studio Code as IDE
      • CircleCI for continuous integration (automatize development process)
      • Prettier / TSLint / ESLint as code linter
      • SonarQube as quality gate
      • Docker as container management (incl. Docker Compose for multi-container application management)
      • VirtualBox for operating system simulation tests
      • Kubernetes as cluster management for docker containers
      • Heroku for deploying in test environments
      • nginx as web server (preferably used as facade server in production environment)
      • SSLMate (using OpenSSL) for certificate management
      • Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
      • PostgreSQL as preferred database system
      • Redis as preferred in-memory database/store (great for caching)

      The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

      • Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
      • Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
      • Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
      • Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
      • Scalability: All-in-one framework for distributed systems.
      • Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.
      See more
      Tymoteusz Paul
      Devops guy at X20X Development LTD · | 23 upvotes · 9.8M views

      Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).

      It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.

      I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.

      We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.

      If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key functionality that must be brought in via plugins (like quality REST API which comes built-in with TeamCity). It also comes with all the common-handy plugins like Slack or Apache Maven integration.

      The exact flow between CI and CD varies too greatly from one application to another to describe, so I will outline a few rules that guide me in it: 1. Make build steps as small as possible. This way when something breaks, we know exactly where, without needing to dig and root around. 2. All security credentials besides development environment must be sources from individual Vault instances. Keys to those containers should exist only on the CI/CD box and accessible by a few people (the less the better). This is pretty self-explanatory, as anything besides dev may contain sensitive data and, at times, be public-facing. Because of that appropriate security must be present. TeamCity shines in this department with excellent secrets-management. 3. Every part of the build chain shall consume and produce artifacts. If it creates nothing, it likely shouldn't be its own build. This way if any issue shows up with any environment or version, all developer has to do it is grab appropriate artifacts to reproduce the issue locally. 4. Deployment builds should be directly tied to specific Git branches/tags. This enables much easier tracking of what caused an issue, including automated identifying and tagging the author (nothing like automated regression testing!).

      Speaking of deployments, I generally try to keep it simple but also with a close eye on the wallet. Because of that, I am more than happy with AWS or another cloud provider, but also constantly peeking at the loads and do we get the value of what we are paying for. Often enough the pattern of use is not constantly erratic, but rather has a firm baseline which could be migrated away from the cloud and into bare metal boxes. That is another part where this approach strongly triumphs over the common Docker and CircleCI setup, where you are very much tied in to use cloud providers and getting out is expensive. Here to embrace bare-metal hosting all you need is a help of some container-based self-hosting software, my personal preference is with Proxmox and LXC. Following that all you must write are ansible scripts to manage hardware of Proxmox, similar way as you do for Amazon EC2 (ansible supports both greatly) and you are good to go. One does not exclude another, quite the opposite, as they can live in great synergy and cut your costs dramatically (the heavier your base load, the bigger the savings) while providing production-grade resiliency.

      See more