- [Instructor] React is for taking data and displaying it. So we should test any part of our application that takes data and renders it. There are two ways we can do this, render a component tree in a test environment and assert on its output or run end to end tests, which as we've already mentioned is not really concerned with React components, but what should we test? According to test carried Kent C. Dodds, "The more your tests resemble the way your software is used, the more confidence they can give you". A good rule of thumb is that you should test anything that does not duplicate the exact application code in the test, it's not a responsibility of, or covered by other tests. Meaning other libraries or reacts to core implementation, or if it has detail is important to outsiders. Meaning can they affect different API internal detail be described using only the components public API. With this in mind, we should be trying to write tests that check the output of our components rather than how they get to the output. The main reason for that is if you refactor your component and you test its implementation, the test will almost certainly break, even if the component produces the required outcome. There are a few strategies that I use to test React apps and some, or all of them can be used. The first is for components that don't often change in your application. The best way to test a component like this, is to make a representation of the DOM it creates and then check that it repeats this representation on testing. This is called snapshot testing, and we'll look into that first when we go more in depth into testing soon. The next strategy, is to render an initial component, perform some interaction with it, and then check to see if that we render results in the output we expected. There are a few ways in which that can be done, but we'll check out Facebook's recommendation for this. To preserve the unit nature of components, we need to understand how we can test those that have dependencies on others, and those that may render other components. To be able to do this effectively, we need to know about mocking strategies for other components and functions that we may import. We've introduced Hooks into our applications, and some of them are built in. There's no need to test the actual Hook, but if the Hook effects our component, we should check if behaves as expected. The flip to that is the custom Hooks we may have made. Like when we covered state management with a context and reduces. The last part of our testing journey will be to test these Hooks. Routing is an interesting area for testing. We use components from the react-router-dom and this is extensively tested, so there's this sort of literal need to test routing. However, there are some things we should test when routing, so it'd be wrong not to discuss them.

Lectures

Introduction to Testing React with Jest - How to set up the Test Environment - Jest - 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