Intro to Confidently Testing Redux Applications with Jest & TypeScript
Best practices for building & testing redux applications have changed dramatically over time. This course aims to be a comprehensive yet understandable resource for those seeking to improve the testing of their redux applications.
This course is broken up into three parts.
The intro is look at how to add jest to an existing react redux application that was built on top of vite. We cover basic functionality like watch mode and generating and using code coverage to inform our testing strategy.
The first section covers the specifics of unit testing the redux code in our application. We'll go over how to test reducers, selectors and thunks. As part of this we'll touch on mocking APIs and using Redux Mock Store as well as running actions through our applications' actual reducers to broaden our test coverage.
Finally we'll look at how we can test our redux connected react components using the various utilities that come with the React Testing Library. We'll cover simulating various kinds of user input with the user-event module, populating our redux store with test data, using jest spy, how to wait for asynchronous tasks to complete, and several approaches for finding & asserting that visual elements exist on the page.
This course is built on top of content that was created for the Modern Redux with RTK and TypeScript course and I highly recommend you start there if you haven't completed it already.
I'm confident you will level up your redux testing abilities if watch these lessons and practice coding each of them as you go.
Jamund Ferguson: [0:00] Jamund here. I just wanted to say thank you for watching this course about testing Redux-connected applications. Redux is a fantastic state management library, but testing Redux applications, at least for me, has always been a major pain. As soon as you wrap the first component in a Redux Provider, testing your app becomes more challenging.
[0:19] In this course, I'm going to cover two main approaches to testing Redux applications. I promise to keep things as simple as possible. With a little practice, you'll be be testing Redux apps like a pro.
[0:33] The first way that we're going to test our apps is by very precisely unit testing each individual piece. Each selector, each thunk, each action, creator, and reducer case is tested in isolation. This allows us to write really clean and straightforward tests for both our Redux code and all of our connected components, but it can leave a few blind spots.
[0:56] The other popular approach to testing Redux applications leans a bit more into integration testing. You start by testing components that are fully connected to your actual Redux store. As your tests interact with those components and fire off various actions that make their way into Redux, you assert that your components are updated with any changes made by your reducers.
[1:16] Your action creators, selectors, and thunks are all going to be tested in the context of the components dispatching or accessing them. These tests can definitely be trickier to set up. Ultimately, this approach provides a higher level of certainty that your Redux-connected components are working as expected.
[1:34] For this course, we're going to cover both of these approaches. I don't want you to leave thinking that one is significantly better than the other. They're both important tools you'll need for testing your application. Both of them can be used side-by-side as we demonstrate in this course.
[1:48] We'll be using TypeScript a lot in this course. For the most part, it won't be a major emphasis. All the lessons we'll learn will be perfectly applicable in JavaScript as they are in TypeScript. Thank you for watching. I hope you learn a lot. Let me know if there's anything I can improve by adding a note in the comments. Thank you.
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!