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!
Latest comments (71)
I think peple who don't use semicolons in their library documentation should not be trusted.
I do not like it.
I get random "should call act" errors depending on which device I run the test. If fireEvent.click needs to be wrapped in act() to be dependable, it should use it itself. Instead I have to wrap it myself every time. My test code is ugly and long-winded.
It promises interaction like the user does, but I can't get "the sort icon beside the column header". It has a function "within" but its use seems to be more for typecasting from HTMLElement to whatever internal type it uses rather than looking in the HTMLElement's children.
I have to step outside the framework to use .closest(..) to find elements "like a user would".
I have to add role, name, and other nonfunctional attributes to several places to my code because I cannot find by icon... because I'm not allowed to find by the class which puts the icon there. (FontAwesome, etc.)
I end up with tests that navigate by a mishmash of screenreader landmarks and visual landmarks, so I have no guarantee that either method of navigation works for either type of user.
I can't string the element, findBy, click calls in a fluent interface. The closest I get is with findBy(...) because I can string on .then(fireEvent.click). But this randomly throws the "act(...)" error depending on device, even when teh whole line has await. So instead I'm forced to write tests that read like a dick-and-jane English primer instead of a more natural style.
I can't get "the only select element on the popup" like a user would because I can't find by HTML tagname.
GetByText gets text from closed dropdowns and non-visible popups, making it largely useless. (Bootstrap3)
Getting an easily visible element by a combination of factors isn't possible. All my column headers have "click to filter" title, all my column headers' texts appear again in a dropdown or two, i actually want the sort icon beside the text in the header but there's one per column.... I can only get/find/query by a single criteria. I'm reduced to array indexes.
I like the idea behind this framework, but it's implementation leaves a lot to be desired.
The rtl is really nice when it works. But it seems have some serious problem when Material UI. I literarily spent more than 2 days still trying to figure out why the userEvent.type won't work on a properly selected input dom via testid.
Its very frustrating
I created an account here just to say: Enzyme…? Better to have called it "pile of shit stacked" 🤮, as you said: "looks like a minefield". Nothing works ... it's, awful, a waste of time using this fucking shit library. I have had a horrible experience using it. The authors would be better off dead.
why the documentation is very much confusing?
I'm sure RTL has been a lot of work and I'm not trying to call you out. It seems you're really passionate about this and legitimately open to feedback.
I think it doesn't solve the biggest problems with testing. Testing should be easy and perhaps even fun. I've yet to ever once try to install RTL on a site and have it just work. Instead I get stuck in configuration land. It does little to improve mocking, which is one of the more frustrating parts of testing, especially for a beginner. Once going is it better than Enzyme? Sure, I guess. But only because it's opinionated and so you do less. I'd say RTL is acceptable but doesn't improve the testing landscape in a meaningful way overall. For those familiar with testing it's a nice little api that's moderately helpful.
I suppose this isn't the goal of RTL. The goal is to test the things that need testing, not implementation details. I think that's a worthy goal, it's just never going to be improved until testing is easy to do. RTL doesn't really move the needle on ease of use. As such it's a needless improvement in my view. You could have done the entire RTL task with a VSCode package that highlights or underlines when bad enzyme practices are being used.
Does React Testing Library work with Apollo?
Yes
I'm using at work and is helping us a lot!
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.
I recently updated the repo to link to this: testing-library.com/docs/example-c...
Thanks!
I just started with @testingLibrary, i never thought testing will become this much simpler with all super cool minimal APIs. Thank you 3000.