…ve so far seen how easy testing real-time socket.io-client app could be with react-testing-library. No matter what you are testing, when you follow this approach, you gain more confidence that your app is working as it should. And what is more, we still have zero ideas what the implementation of the app will look like. Just as the user, OUR TEST JUST DON’T CARE ABOUT THE IMPLEMENTATION!
getByTestId does not closely resemble how users locate sections of your app, you should use it only on spacial cases, only when your’re certain there is no better alternative. Still, our test is not relying on the DOM structure. Even if someone, changes the
div to a
section tag or have it wrapped 10 levels deep in the DOM, our test doesn’t just care about the code, just the test-id.
…contains all the messages. Only if messages appear in that section will he know he’s got a message.
So to make sure our test resembles how the user is using our app, we’ll need to
search for the text ‘Hey Wizy!’ only within the messages-section, just as the user.
Following the react-testing-library approach, the first thing you do before you write any test is to ask yourself: “How will a user test this feature?” For the first test in our list above, you ask yourself, “how will a user know that he’s getting the…
It was a few months ago that my friend and mentor Kent C. Dodds released this beautiful tool for testing react apps. Ever since then, I no longer just love the idea of testing UIs, but actually loving and testing more UIs. I have literally dug out and tested all UI codes I gave up on testing because of their complexity :) In my experience-based opinion, react-testing-library is the panacea for all UI test issues. It is not just a testing tool, it is a testing approach.