I wrote React Testing Library about a year and a half ago because I was teaching testing workshops and I wasn't happy with enzyme. I felt like there was so much I had to tell people to not use in enzyme (like the API was some kind of mine field). So I created React Testing Library and I've been very happy with it.
I'd love to hear what others think. And have you had a chance to use any other members of the Testing Library Family, like DOM Testing Library, Cypress Testing Library, Vue Testing Library, etc? I'd love to hear your thoughts on that too!
Oldest comments (71)
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. 🙂
My blog has tons of stuff. Search for "testing". Also, TestingJavaScript.com is a fantastic resource.
Awesome, thank you very much Kent.
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.Super awesome to see you posting on dev.to!!!! :)
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).
The #discuss tag is just for that!
#discuss
Yep, see here:
dev.to/bdbch/comment/d8mn
I agree add #discuss :)
Done! Thanks folks!
We have some long overdue design improvements on the editor to help people select the right tags, so it's great to see this meta discussion help folks out.
Kent, between this and your other couple posts I think you're making really great use of the format of the site and look forward to more of this community-enabling content; using your de facto leadership role in JS/React to spark a lot of great discussions that have a bit more lasting value than a Twitter thread.
👏👏👏
Ben...what do you think about react testing library lmao
I believe the #discuss tag is normally used for that. 😉
Can you exclude this tag when you want to fetch it via the articles endpoint?
I'd like to integrate dev.to into my website instead of medium but wouldn't like to see my discussion posts in there. :)
Sure could filter out on my side, but that would break the pagination.
Not sure. I haven't used the API yet. Maybe the docs can provide you a hint. 👌
@bdbch if you're just trying to page through your own articles, you can probably just pull in the whole dang list and do whatever sorting and paging you want on the client. You'd have to write a ton of articles for that to be a problem. Different story if you're pulling more that just your own, but in that case you'll probably have a more specific query anyway
Thats true, guess thats the best way to go from here on! :)
You could do that if you like. I think you'll find that it's pretty easy to get up and going though. You can even try it in the very same file that you're using enzyme in as well! So migrating is a pretty simple process.
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 think JSDOM only provides DOM APIs. It isn't a full-blown rendering engine which is required to determine element's visual and structural properties. You'd have to use some visual testing tool to validate the behavior you described.
That’s what I concluded after tests but really wanted to test this case programmatically. I guess visual testing it has to be then.
You could check the styles or classes being applied at least and trust that the CSS is doing it's thing.
Yep, that's what I'd recommend. You could also use the
styleprop and verify the node.style.width is correct.Thanks, will try!
Would that really work in this case, i.e., when width is not specified by a CSS class?
With JSDOM, you can't measure layout, but you can verify that the style/class name was applied and trust that in the browser's ability to lay it out properly based on that.
Got it! Thanks! 😄
Is there a way to simulate events in RTL like Enzyme’s .simulate()?
The docs have some good examples of how to trigger events.
Yep! That would be
fireEventAPI.Yes, though they're not simultated events. They're actual events like the ones the browser will fire when the user interacts with your component. Check it out here: testing-library.com/docs/dom-testi...
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 really enjoy how we can just access elements in the DOM and how context and hooks just work.
What are some of the "land mines" in enzyme that you try to steer people away from?
.instance().state(),.setState(),.props(),.setProps())displayName(like.find())Fundamentally, it's about testing implementation details, which enzyme enables and encourages. This leads to very poor tests which have many false positives and false negatives. Learn more from my blog post Testing Implementation Details.
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!
That's great to hear!
I think a lot of people jumped on with the hooks thing. Enzyme now supports hooks (mostly anyway), but I think people are discovering that react testing library is a better way to test components anyway.
Inertia is hard to beat, so it will be a very long time before RTL has more downloads than enzyme, but I do believe it will happen eventually.
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.