Alternatives to react-testing-library logo

Alternatives to react-testing-library

Enzyme, Cypress, Jest, JUnit, and Cucumber are the most popular alternatives and competitors to react-testing-library.
166
114
+ 1
3

What is react-testing-library and what are its top alternatives?

It is a simple and complete React DOM testing utility that encourage good testing practices. It provides light utility functions on top of react-dom and react-dom/test-utils, in a way that encourages better testing practices.
react-testing-library is a tool in the Testing Frameworks category of a tech stack.
react-testing-library is an open source tool with GitHub stars and GitHub forks. Here’s a link to react-testing-library's open source repository on GitHub

Top Alternatives to react-testing-library

  • Enzyme

    Enzyme

    Enzyme is a JavaScript Testing utility for React that makes it easier to assert, manipulate, and traverse your React Components' output. ...

  • Cypress

    Cypress

    Cypress is a front end automated testing application created for the modern web. Cypress is built on a new architecture and runs in the same run-loop as the application being tested. As a result Cypress provides better, faster, and more reliable testing for anything that runs in a browser. Cypress works on any front-end framework or website. ...

  • Jest

    Jest

    Jest provides you with multiple layers on top of Jasmine.

  • JUnit

    JUnit

    JUnit is a simple framework to write repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks. ...

  • Cucumber

    Cucumber

    Cucumber is a tool that supports Behaviour-Driven Development (BDD) - a software development process that aims to enhance software quality and reduce maintenance costs. ...

  • PHPUnit

    PHPUnit

    PHPUnit is a programmer-oriented testing framework for PHP. It is an instance of the xUnit architecture for unit testing frameworks. ...

  • Mockito

    Mockito

    It is a mocking framework that tastes really good. It lets you write beautiful tests with a clean & simple API. It doesn’t give you hangover because the tests are very readable and they produce clean verification errors. ...

  • RSpec

    RSpec

    Behaviour Driven Development for Ruby. Making TDD Productive and Fun.

react-testing-library alternatives & related posts

Enzyme logo

Enzyme

459
328
0
JavaScript Testing utilities for React, by Airbnb
459
328
+ 1
0
PROS OF ENZYME
    Be the first to leave a pro
    CONS OF ENZYME
      Be the first to leave a con

      related Enzyme posts

      Russel Werner
      Lead Engineer at StackShare · | 7 upvotes · 140.7K views

      We use Jest because when we rebooted our "front end" stack earlier last year, we need to have a testing solution (we didn't have any front-end tests before that!). Jest is fast and convenient and it has plenty of community support behind it. It let's us run our unit tests with Enzyme and snapshot tests.

      This is an area that we are constantly reviewing to see what can be improved, both in terms of developer needs, accuracy, test maintainability, and coverage.

      I'm currently exploring using React Storybook to be the record of snapshot tests and using some online services, such as Happo.io and Percy in our CI pipeline.

      See more

      I use both mocha and Jest because:

      • I don't care whether teams use Jest or Mocha. But jest is way too overhyped. Most devs are writing integration tests and think that it's so much better but frankly I don't write integration tests as the way to get both design feedback and confidence when I code. I adhere to the test pyramid, not ice cream cone or the dumb "trophy"

      • I TDD, so I only ever use the "API" of test frameworks. I don't do a lot of integration tests for TDD and all the bells and whistles Jest provides you from the command-line I just don't need. And I certainly do not care about or touch Jest Snapshots, I despise them

      • My tests are fast enough because I write isolated tests with TDD, so I don't run into performance issues. Example: I write my tests in a way that I can run 300 tests in literally 1 second with mocha. So the Jest ability to pinpoint and only run those tests which are affected by code changes. I want to run all of them every time when I TDD. It's a different mindset when you TDD

      • I also mainly code in IntelliJ or WebStorm because I feel the tools in that IDE far surpass VSCode and I also love running the test UI runner in it vs. lousy command-line

      • I feel both mocha and Jest read just fine in terms of code readability. Jest might have shorter assertion syntax but I don't really care. I just care that I can read the damn test and my tests are written well and my test descriptions, as well as the code itself including constants represent business language, not technical. I care most about BDD, clean code, 4 rules of simple design, and SOLID

      • I don't like using mock frameworks so no I don't use Jest's Mocking framework. I don't have to mock a lot in my tests due to the nature of how I strive to code...I keep my design simple and modular using principals such as clean code and 4 rules of simple design. If I must mock, I create very simple custom mocks with JS

      • On the contrary to the belief that integration tests and mount are the way to go (this belief drives me absolutely crazy, especially Dodd's promoting that), I TDD with shallow & enzyme. My tests are simple. My design is driven by my tests and my tests give me quick and useful feedback. I have a course I'm working on coming out soon on TDD with React to show you how to truly test the FE and why the ice cream cone and trophy suck (you're being scammed people). Watch for that here: https://twitter.com/DaveSchinkel/status/1062267649235791873

      Don't forget to upvote this post!

      Mocha Jest JavaScript React @jsdom Enzyme #tdd #bdd #testdrivendevelopment

      See more
      Cypress logo

      Cypress

      1.3K
      1.5K
      102
      When testing is easy, developers build better things faster and with confidence.
      1.3K
      1.5K
      + 1
      102
      PROS OF CYPRESS
      • 25
        Open source
      • 19
        Great documentation
      • 17
        Simple usage
      • 17
        Fast
      • 10
        Cross Browser testing
      • 9
        Easy us with CI
      • 4
        Npm install cypress only
      • 1
        Good for beginner automation engineers
      CONS OF CYPRESS
      • 19
        Cypress is weak at cross-browser testing
      • 12
        Switch tabs : Cypress can'nt support
      • 11
        No iFrame support
      • 8
        No file upload support
      • 8
        No xPath support
      • 8
        No multiple domain support
      • 8
        No page object support
      • 7
        Re-run failed tests retries not supported yet
      • 7
        Cypress doesn't support native app
      • 7
        No support for multiple tab control
      • 6
        No support for multiple browser control
      • 6
        No support for Safari
      • 4
        $20/user/thread for reports
      • 4
        Not freeware
      • 4
        Adobe
      • 3
        No 'WD wire protocol' support
      • 3
        Using a non-standard automation protocol

      related Cypress posts

      Kamil Kowalski
      Lead Architect at Fresha · | 27 upvotes · 1.2M 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
      Robert Zuber

      We are in the process of adopting Next.js as our React framework and using Storybook to help build our React components in isolation. This new part of our frontend is written in TypeScript, and we use Emotion for CSS/styling. For delivering data, we use GraphQL and Apollo. Jest, Percy, and Cypress are used for testing.

      See more
      Jest logo

      Jest

      3.4K
      2.6K
      169
      Painless JavaScript Unit Testing
      3.4K
      2.6K
      + 1
      169
      PROS OF JEST
      • 35
        Open source
      • 31
        Mock by default makes testing much simpler
      • 22
        Testing React Native Apps
      • 19
        Parallel test running
      • 15
        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
      • 6
        One stop shop for unit testing
      • 6
        Promise support
      • 3
        Great documentation
      • 2
        Assert Library Included
      • 1
        Preset support
      • 1
        Built in watch option with interactive filtering menu
      • 0
        Can be used for BDD
      CONS OF JEST
      • 3
        Documentation
      • 3
        Ambiguous configuration
      • 2
        Ambiguous
      • 2
        Multiple error messages for same error
      • 2
        Difficult
      • 2
        Many bugs still not fixed months/years after reporting
      • 2
        Difficult to run single test/describe/file
      • 1
        Bugged
      • 1
        Reporter is too general
      • 1
        BeforeAll timing out makes all passing tests fail
      • 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

      Robert Zuber

      We are in the process of adopting Next.js as our React framework and using Storybook to help build our React components in isolation. This new part of our frontend is written in TypeScript, and we use Emotion for CSS/styling. For delivering data, we use GraphQL and Apollo. Jest, Percy, and Cypress are used for testing.

      See more
      Shared insights
      on
      CypressCypressJestJest

      As we all know testing is an important part of any application. To assist with our testing we are going to use both Cypress and Jest. We feel these tools complement each other and will help us get good coverage of our code. We will use Cypress for our end to end testing as we've found it quite user friendly. Jest will be used for our unit tests because we've seen how many larger companies use it with great success.

      See more
      JUnit logo

      JUnit

      1.4K
      467
      0
      A programmer-oriented testing framework for Java
      1.4K
      467
      + 1
      0
      PROS OF JUNIT
        Be the first to leave a pro
        CONS OF JUNIT
          Be the first to leave a con

          related JUnit posts

          We are looking for a Testing Tool that can integrate with Java/ React/ Go/ Python/ Node.js. Which amongst the three tools JUnit, NUnit & Selenium would be the best for this use case?

          See more
          Joshua Dean Küpper
          CEO at Scrayos UG (haftungsbeschränkt) · | 1 upvote · 147.5K views

          We use JUnit for our Java Unit and Integration tests in Version 5. Combined with @JMockit2 and @truth (from Google) we perform all kinds of tests on our minecraft, standalone and microservice architecture.

          We prefer JUnit over TestNG because of the bigger community, better support and the generally more agile development. JUnit integrates nicely with most software, while TestNG support is a little more limited.

          See more
          Cucumber logo

          Cucumber

          743
          728
          32
          Simple, human collaboration.
          743
          728
          + 1
          32
          PROS OF CUCUMBER
          • 20
            Simple Syntax
          • 5
            Simple usage
          • 4
            Huge community
          • 3
            Nice report
          CONS OF CUCUMBER
            Be the first to leave a con

            related Cucumber posts

            Benjamin Poon
            QA Manager - Engineering at HBC Digital · | 8 upvotes · 771.7K 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
            Sarah Elson
            Product Growth at LambdaTest · | 4 upvotes · 334.3K views

            @producthunt LambdaTest Selenium JavaScript Java Python PHP Cucumber TeamCity CircleCI With this new release of LambdaTest automation, you can run tests across an Online Selenium Grid of 2000+ browsers and OS combinations to perform cross browser testing. This saves you from the pain of maintaining the infrastructure and also saves you the licensing costs for browsers and operating systems. #testing #Seleniumgrid #Selenium #testautomation #automation #webdriver #producthunt hunted

            See more
            PHPUnit logo

            PHPUnit

            465
            225
            12
            Testing framework for PHP
            465
            225
            + 1
            12
            PROS OF PHPUNIT
            • 4
              TDD Unit Testing
            • 2
              TDD Integration Testing
            • 2
              TDD Acceptance Testing
            • 1
              Software Quality
            • 1
              TDD Unit Testing
            • 1
              Unit Testing
            • 1
              The de facto standard for xUnit testing in PHP
            CONS OF PHPUNIT
            • 1
              Mocked services require more effort and understanding

            related PHPUnit posts

            Shared insights
            on
            BehatBehatPHPUnitPHPUnit

            What is the best solution (PHPUnit or Behat) for test automation (unit and functional tests)?

            See more
            Mockito logo

            Mockito

            444
            123
            0
            Tasty mocking framework for unit tests in Java
            444
            123
            + 1
            0
            PROS OF MOCKITO
              Be the first to leave a pro
              CONS OF MOCKITO
                Be the first to leave a con

                related Mockito posts

                RSpec logo

                RSpec

                441
                167
                0
                Behaviour Driven Development for Ruby
                441
                167
                + 1
                0
                PROS OF RSPEC
                  Be the first to leave a pro
                  CONS OF RSPEC
                    Be the first to leave a con

                    related RSpec posts

                    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
                    Simon Bettison
                    Managing Director at Bettison.org Limited · | 7 upvotes · 296.1K views

                    In 2010 we made the very difficult decision to entirely re-engineer our existing monolithic LAMP application from the ground up in order to address some growing concerns about it's long term viability as a platform.

                    Full application re-write is almost always never the answer, because of the risks involved. However the situation warranted drastic action as it was clear that the existing product was going to face severe scaling issues. We felt it better address these sooner rather than later and also take the opportunity to improve the international architecture and also to refactor the database in. order that it better matched the changes in core functionality.

                    PostgreSQL was chosen for its reputation as being solid ACID compliant database backend, it was available as an offering AWS RDS service which reduced the management overhead of us having to configure it ourselves. In order to reduce read load on the primary database we implemented an Elasticsearch layer for fast and scalable search operations. Synchronisation of these indexes was to be achieved through the use of Sidekiq's Redis based background workers on Amazon ElastiCache. Again the AWS solution here looked to be an easy way to keep our involvement in managing this part of the platform at a minimum. Allowing us to focus on our core business.

                    Rails ls was chosen for its ability to quickly get core functionality up and running, its MVC architecture and also its focus on Test Driven Development using RSpec and Selenium with Travis CI providing continual integration. We also liked Ruby for its terse, clean and elegant syntax. Though YMMV on that one!

                    Unicorn was chosen for its continual deployment and reputation as a reliable application server, nginx for its reputation as a fast and stable reverse-proxy. We also took advantage of the Amazon CloudFront CDN here to further improve performance by caching static assets globally.

                    We tried to strike a balance between having control over management and configuration of our core application with the convenience of being able to leverage AWS hosted services for ancillary functions (Amazon SES , Amazon SQS Amazon Route 53 all hosted securely inside Amazon VPC of course!).

                    Whilst there is some compromise here with potential vendor lock in, the tasks being performed by these ancillary services are no particularly specialised which should mitigate this risk. Furthermore we have already containerised the stack in our development using Docker environment, and looking to how best to bring this into production - potentially using Amazon EC2 Container Service

                    See more