12/17/2023 0 Comments Jest mock websocket![]() Let’s see some more query methods that the react-test-library gives us. If the text is not found, getByText will throw and fail our test.Īnd that’s how we assert that the App can get messages. Lastly, we use the within method as described earlier to get the received message. Even if someone changes the div to a section tag or wraps it 10 levels deep in the DOM, our test doesn’t just care about the code - it just cares about the test-id. Still, our test is not relying on the DOM structure. Like so:īecause getByTestId does not closely resemble how users locate sections of your app, you should use it only on spacial cases and only when you’re certain there is no better alternative. To use getByTestId in your test, you have to hard-code it in the DOM. let EVENTS = )įirst, we grabbed the message section with a query method getByTestId. Once you understand how to mock, the next thing is understanding what your module is doing, and then fake the implementation. For more information on mocking, see Kent’s article “ But really, what is a JavaScript mock?” as well as this section from the Jest docs on Jest’s Mock Functions. Now as I was writing this line, I was thinking he should just write a book on JS testing so I tweeted:īack to our test file: // React from 'react' import io from 'socket.io-client' import Chat from './chat' īecause, we’re only doing integration testing here, we don’t really want to emit socket.io events to the server. He’s got everything covered on JavaScript testing, so just follow him on here, Twitter, and everywhere else. If you’re new to mocking or stuff like that, then Kent C. First, create a test file, then import the chat.js file and its mocked dependencies. Let’s look at how a user would know if they received a message as an example. Okay, the list goes on…but let’s work on these first. App should tell when a friend is typing.App should tell when a friend comes online/goes offline.App should tell when/if a message is delivered or not.App should tell when/if a message is sent or not.Looking at the design, I see a couple of real-time features our user would want to make sure the app performs, otherwise they’ll close the tab. Now let’s do it! Testing out the Telegram appįrom our very talented Telegram UI designer, bellow are the designs of the Telegram app we’ll be testing. This is how we’re going to write our socket.io-client test - test everything without thinking about the code. That gives us the power to use TDD on our UIs. Your user probably neither knows nor cares what your code looks like. Test your UIs just as your non-techie friend would. This is the “approach” I’m talking about. According to the docs, it’s primary guiding principle is: The more your tests resemble the way your software is used, the more confidence they can give you. The best feature of the react-testing-library is probably its support of UI TDD. Note: If your’re not a React person, there is vue-testing-library, ng-testing-library and others, all built on top of the dom-testing-library. It is not just a testing tool, it is a testing approach. In my experience-based opinion, the react-testing-library is the panacea for all UI test issues. I have literally dug out and tested all the UI code I gave up on testing because of its complexity :). Ever since then, I no longer just love the idea of testing UIs, but actually love testing them. Dodds released this beautiful tool for testing react apps. It was a few months ago that my friend and mentor Kent C. But then, unto us a UI testing tool has been born! react-testing-library It is only the UI that makes our user confident that they’re actually accomplishing the purpose of using our app. Thus, people tend to focus their time and energy on testing their socket.io apps only on the server-side.īut that doesn’t feel right. The testing tools we have had available to us easily lead to writing very brittle UI tests. ![]() User Interfaces have had a long history of testability issues. ![]() My guess is: Testing UIs was just too hard! No one is talking about the quality of socket.io-client integration on the front-end, how the User Interface will look when it receives certain events, and if the front-end code is actually emitting the right events.īut why? Does this just mean that people don’t really care about the quality of their real-time apps on the front-end - the meat of the software? I don’t think so. The first two result pages (just don’t bother opening the rest of the pages) are all examples and tutorials focusing on testing the server-side socket.io integration. Testing the quality of real-time Socket.io-client integration seems to have sunk into oblivion, maybe because the UIs had a long history of testability issues. By Justice Mba How to test a Socket.io-client app using Jest and the react-testing-library Photo by freestocks on Unsplash ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |