Happy to see you over here at dev.to! :) To be honest I'm still very unexperienced with testing. Should I do it with a test project first to get into it?

(Also a cool feature for dev.to would be to mark specific posts as discussions, I'd like to use dev.to as my blog on my website).

Overall I think it's great and solves many of the issues with enzyme.

My favorite parts are:

1. It prevents you from accessing the instance. This is the most common testing mistake I see in the code bases I work on-- calling .instance() and then directly invoking an internal method for testing.

2. It prevents you from querying by the component name, e.g. expect(wrapper.find(MyComponent)).toEqual(...). This is especially an issue when writing integration tests with enzyme, as the component structure is really just an implementation detail at that point. I think static rendering (render()) might be a better option, but most people just seem to use mount. In any case, that leads to my next point:

3. Much smaller, simpler API. Enzyme provides so much functionality that it can be really hard to figure out the right approach for a given situation. Even worse is that much of the functionality can lead to really brittle tests. There's just a lot less decision making with RTL.

I'll start. I love it! It enables me to write tests that resemble the way my software is used which gives me more confidence and makes tests easier to write (and read). I only need to change my tests when I actually change my app's behavior, and my tests actually help me catch bugs. Also, the fact that I don't have to change my tests as I refactor to hooks (and it handles the act() calls for me) is fantastic.

We picked up React Testing Library when we made the jump to React Hooks and were looking for a testing platform that supported it (enzyme did not). In the process we found that with RTL we could write better integration style tests with fewer test files and better code coverage.

Personally, I love the ideology behind RTL. Forcing your tests to interact with the DOM the way your users will makes the tests far more robust and descriptive and promotes much more expressive UI design.

As a side note, I love the updates that I have been seeing to RTL and the surrounding libraries. Great job!

I've been using RTL personally and love it so far. The ideology behind it makes so much sense.

However, I have to use Enzyme at work and it makes following the idea behind RTL so much harder. Finding elements with Enzyme returns a bunch of implementation details that don't usually don't really help.

I had tried to convince the frontend architect at my company to switch over to RTL for testing. He had tried it but didn't like it for a couple of reasons:

• There is no shallow rendering (I believe he loves unit testing components). He believes that each component and test should be isolated from one another, so that tests would not bleed into one another, making tests less brittle than rendering the entire tree.
• Rendering the entire tree with RTL makes it really ez to have huge, unmaintainable tests. I told him it is possible to unit test with RTL, but he said the fact that the default is full DOM rendering just makes it to ez to not unit test.

I had argued that shallow rendering does not give the confidence that the code works, but he said there needs to be a balance for maintainability. I proposed adding RTL to the codebase to allow everyone to try it out but he argued that when a developer encounters a test in RTL, the developer would have to learn a whole different set of testing API to make changes to the test.

I honestly still think RTL makes the better trade-off though because I followed its ideology in Enzyme and it has actually caught bugs for me.

So far so good. I had one case however where I was unable to figure out one test case.
I have a button, that button has text. Upon clicking the button, the text gets replaced by a spinner. Thing is, the width of the button should stay the way it was when text was inside and not squeeze to be spinner sized. I did a simple render, put the width of the component in a variable and then fired a click event. I then tried getting the width and seeing if it matched. It was 0 all the time. I’m a bit new to testing but assumed JSDom or JestDom is being used when I render() the component and it would simulate properly. I even tried wrapping the button in a container div with preset dimensions. No luck still. For other unit tests it was a breeze. It really made me rethink how I test my Frontend.

I love it! I constantly trying to push the library and thinking paradigm on everyone.

At the very least at my work, since they are still going to use Enzyme, I constantly am encouraging people to learn and research the paradigm (philosophy) that you have written about and the entire react-testing-library is built around... Ever since then, I have become the "go-to guy" for unit testing questions, I also have now done a few internal pieces of training. The tests have significantly improved, the coverage has increased and people have a better idea of WHY they are creating the tests just from shifting that mindset alone!

I love it and so does my team. I was an early adopter and introduced it to the team as an alternative approach to ReactTestUtils/snapshots. Testing components and workflows from the user's POV gives us enormous confidence and the ability to find elements using a11y tags kills two birds with one stone. We use it in conjunction with jest-dom and are over the moon with how reliable the products are.

The only real testing pain we've encountered has been lack of async act support but React 16.9 will fix this and we found plenty of useful workarounds thanks to conversations on the @testing-library/react GitHub page.

So thank you Kent and all the project contributors. Long live @testing-library!

It's the shit. My coworkers and I love it. I think enzyme, frankly, is weird as fuck (wtf is shallow rendering and what does .dive do? I don't get it).

Everything about react testing library so far has been really awesome. Easy to set up, easy to use, encourages testing UI the right way, and is just generally dope af. Much respect.

Love it

I wrote tests for almost two years with jasmine and karma for Angular project.

Now I'm working with react, react testing library and wallabyjs and tests is not pain anymore. For me it was huge improvements in my workflow and I feel much more productive.

Really love RTL. We’re almost exclusively enzyme for frontend tests at work, but I’ve started introducing RTL in a few projects and everyone is really digging the design philosophy of it. Excited to keep using it going forward 👍

I strongly agree with the guiding principles of RTL and have been using it for all new development that I can (specifically with the new Marko RTL wrapper). It has allowed us to catch severally A11Y issues already which is amazing since we already tried to avoid testing implementation details but making it easier to do goes a long way.

Having said that my current thinking is that for components there are really two people that need to be tested for. One is for the end user consuming your app, which is handled perfectly by RTL. The other of course is the consumer of the components.

In most frameworks the component consumer is interacting via props and events which are the public api for a component. To the end user it is an implementation detail, but it isn’t to the consumer. Having the ability to render and rerender components exists and is perfect for testing the prop API for components and there is usually some mechanism for testing events from the component such as spy’s. I definitely agree that accessing the component instance is not something the consumer would do and is an implementation detail, but testing props and events is and should be recommended to be tested.

All that is to say, I think RTL’s framework wrappers mostly handle that well, but I don’t feel like that clarification is made on the site. Primarily the wording appears to be about testing for the end user, which is great, but also the public api for components needs to be tested for the consumers of the component, which is often props and events emitted.

Unrelated, I have also been trying to reconcile the reasons why shallow rendering is so popular given the flaws that you mention in your article. I feel that your article highlights important points but might be a tad too absolute in its recommendation to avoid shallow rendering.

I think that using shallow rendering (especially with snapshots) does next to nothing as you say in terms of actually testing for the end user since 99% of the snapshot is testing implementation details. However I do think snapshots provide benefit to developers. They tell you when relevant sections of code has changed so that you can quickly and easily audit it, similar to comparing changes with git, except isolated to what an individual components renders.

However you could of course snapshot the entire rendered dom which would in fact give you more information about what was rendered, however I think at that point the level of noise is too much (similar to giant PR’s that no one wants to review) and so I think people opt for shallow rendering.

In Marko we are experimenting with a new technique which aims to snapshot the entire render tree while including minimal details about your child components. We are doing a full render of components (which means our equivalent of render props actually run which is nice!) and then are going to add the ability to clone the rendered DOM and strip out all nodes not owned by the component which you are testing. Meaning if you render a child component and pass children to it, only the children you passed would be in the snapshot, nothing rendered by the child.

And to end my list of ramblings, I feel that RTL (especially often being limited to JSDOM) is missing some tools to test as a user would, ie simulated scrolling, resizing, perhaps simpler tools for mouse and touch interactions as well? Perhaps good candidates for @testing-library/user-events.

Curious what your thoughts are on all this and thanks for your great work on this suite of tools!

I really enjoy how we can just access elements in the DOM and how context and hooks just work.

I like the focus on testing via the DOM.
I found that my tests for form fields interactions made my React more accessible, since I decided to use Labels and aria-labelledby tags properly.
I also found that using title instead of data-testid led to more understandable buttons for the end user as well.
Overall, great work.
If I had even one suggestion, it would be to make the examples repo more interactive, perhaps with a demo or "playground" page where one can see the library in action.

What resources would you recommend for learning frontend unit testing? I've written unit tests in the past but now I'm planning on learning it properly. TIA. 🙂