- [Instructor] Should we test if props or rendered? Yes, we should. Apart from any default props that are supplied, default props are part of the core React code. And as such, their rendering function is already tested. Do we need to test if prop types work? No, this is the concern of the prop types package and tests already exists for this. What we should do is see if the value of props received is rendered, especially if it can change at one time because the component receives a new value for its props. To test the component that has props we're gonna use the test render object again. And find elements in the component that render based on the props. The root of the test renderer can give us an object that allows us to find other elements within the component. We'll use helper methods of the test instance, such as find all by type and find all by props to help us locate other test instances within the three. The children object contains the contents for these instances, and we will assert against them. To show you some testing, we're using that component that we made earlier in the course. And you can see its code now. Note, the class names were given to the JSX expressions returned on lines eight and 14. These will be used in the testing. In the test file, we start by declaring a test suite. This component receives a lot of props, which means lots of tests. So we are grouping similar tests here. As we want to render the same component with the same prompts over and over again, we set some fixtures for the test. We did a components test. This is defined so we can render it in the before reach function. We want to have a stable set of props that we can assert against. So we define an object to use in both props and our assertions. It has the keys and values that meet the component specified prop types. Remember, we're not gonna test the prop types as this is not our direct concern in this component. The before reach function does two things here. It creates a test instance using the create function on the component with props. Note, how we pass in the props object using the spread operator. The second thing we create is a root test instance object. This allows us to find other nodes within this component. The first test that you can see test the h1 render. We find the first h1 and the three using the find by type function. We pass in the element selector is a string. We then assert on this accessing the child array, which in our case is a single text node that should contain the same string I supplied in the header prop key of the props object. There's no need to test this component without the header text prop because this concern of React to core implementation. And we assume that this renders if we don't supply anything. In the second spec in the file, we've had to use a different find function. Unlike HTML's query selector, which returns to the first match, find by type expects to only find one of the specified type in the tree. If it finds more than one, it returns in error. So we have had to use the find all by type function, which returns in array of matches. We know that we are only concerned with the first element in this test. So we've added the element index in square brackets after the call to access the first paragraph. The assertion is as for the previous test, checking that the child value is the same as the supply prop. We mirrored these tests for the next four specs. For paragraphs with indexes one to four, using slightly different matches and values. Note, that we actually called function prop on line 64 to get its value. This is the last spec you can see on the screen. The next number displays render by an array. We may be satisfied if this is rendered as the correct number of child elements while we may wish to check the actual values. That I suppose is the decision for you. We have opted to check each render of each of the paragraphs, failing if just one is wrong. We've also checked each of the renders from the object props display array. We access each array and check the correct value for key has been used along with the correct value attached to that key. You'll notice in both cases, we've used the class name prop of the JSX expression generated in the component to find the element we wish to test. You can access any prop apart from key and ref in the find all by props and find by props functions. Key and ref are reserved by React and throw an error if you try and access them in tests. There's no need to test the render of the unsupplied prop as this is a concern of React itself. And it's supplied with a default anyway. Obviously if we're following test-driven development, we'd want test to fail. We can supply failing values in the second half of our assertions before supplying the passing value if we're using this methodology. So if we run a test, we have, you can see that they all pass. The console gives us options for rerunning tests. A or Enter to run all. F to run only failing tests. And Q to quit back to the terminal line. So now you've seen what you need to test and how to do it when you're thinking about testing components that receive props.

Lectures

Introduction to Testing React with Jest - How to set up the Test Environment - Jest - The What and How of Testing in React - Snapshot Testing - Testing Components with Props - Mocking Components for Testing - Testing State Events Interactions - Mocking Functions - Testing Components Asynchronously - Testing Components with Routing - Testing Custom Hooks