Testing Redux Connected React Components with React Testing Library (Basic)
There's kind of a lot going on in this lesson, even though it's meant to be basic. I'll try to break down the key parts.
Anytime you have a redux-connected component it must be rendered inside of a redux <Provider>. That's going to be true here in the case of all of our tests, so it's critical we find a way to do that easily, hence our renderWithContext method that we'll use in all of our future tests.
getByRole is a testing library utility that synchronously queries the DOM by looking at the accessible roles assigned to the elements on the page. This is likely not how you're used to thinking about your app, but it is a practice that's worth learning. It specifically was chosen to encourage treating accessibility as a first-class citizen when it comes to building & testing your apps, so use it. The getByRole method that's a property of screen will search the entire rendered document.
toBeInTheDocument() comes from the jest-dom extension and simply confirms that this thing exists. We technically don't need it here, because getByRole will throw when it can't find an element with that role.
This is the only redux-connected component we have that relies on react router, so it's probably overkill to include it in renderWithContext and instead we could make sure to include <Router> in each individual test .
There's a really advanced version of our renderWithContext method referenced in the Writing Tests section of the redux docs, but I like the one I used here a lot better.
Jamund Ferguson: [0:00] If you run the app, you can see up in the upper right-hand corner this little Redux-connected component called the CartLink. It responds when you add items to your cart. When you update the quantity or remove items from your cart, it updates as well. Of course, it acts as the only link to our Shopping Cart page.
[0:16] In your cart folder, add a new file called CartLink, notice the uppercase, .test.tsx. Inside that file, go ahead and import React from "react". Import render and screen from "@testing-library/react". Go ahead and import CartLink from "./CartLink".
[0:38] Now, type test("should contain a link"). Pass in that an arrow function. Inside of it, we're going to render our CartLink component, going to take no props. Then, we're going to expect(screen.getByRole("link")).toBeInTheDocument().
[0:57] We're rendering the CartLink component here. We know that inside of that, there should be a link. That link should end up in the document.
[1:03] Let's open up the terminal window. We are going to run npx jest -- CartLink. Even though this is a very simple test, it failed. The reason it failed can be found here, "Could not find react-redux context value; please ensure the component is wrapped in a provider."
[1:21] This unfortunately is what happens when you bring Redux into your app. Your test of these components gets a lot more complicated, but as I'll show you, we've got this.
[1:28] At the top of your file, go ahead and import Provider from "react-redux". Import store from "../app/store". At the bottom of the file, let's add this helper function, function renderWithContext, which is going to take a single argument, element, of type React.ReactElement. That function is going to render Provider passed-in store and then our element as its child.
[1:56] We'll switch render up here in our test to renderWithContext. We'll save that. Rerun the test. It failed again. This time, because it was expecting another context value. This one, for React router.
[2:10] Let's go ahead and import that as well. At the top of the file, import BrowserRouter as Router from "react-router-dom". Inside of our renderWithContext() method, we can add router as a wrapper around our element. Save that method. We run our tests, that actually worked.
[2:30] Anytime we need to render Redux-enabled components, we have to wrap it in a Redux Provider. Here, we've created this helper method, renderWithContext, to make that process easier.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!