This test starts us off with testing a reducer and we do that by import both the reducer and an associated action creator, which we can use to generate an actions to pass back into that reducer.
For all of our unit tests here we use describe
blocks to group them even though they're not strictly required. When using this approach a good way to think about naming your tests is if you construct a sentence starting from the describe block text and then concluding with the test name passed into it
. For example you can read one of these tests as "products reducer should convert the products received to an object".
One thing we use extensively in our tests is the products json file that we share with our app. In practice, your app likely won't have a products.json
file. That data likely will come from something a bit more dynamic like an API and so you might need to create a file like this just for your tests.
If you're just getting started with jest you can checking out their getting started guide or choose from whole slew of jest lessons here on egghead. Another fantastic resource is Kent C. Dodd's https://testingjavascript.com/ which is a paid course.
Jamund Ferguson: Inside of Products, in the Features folder, create a new file called productslice.test.ts. Now let's open up productslice.ts and see what it is that we'll be testing. If you look at this file, there's really not a lot going on here, except for this one reducer method when we receive new products.
You can see that it takes a payload with an array of products. It converts them into an object, which gets saved on the internal Redux state for this slice. Let's go ahead and test it now.
Back in productslice.test.ts, import productsReducer from ./productSlice. We also want to import a named export called productsReceived. Now, below that, type describe. We'll be describing the productsReducer, pass an error function. Then we'll write a simple function that says, "It should return the initial state and passed an empty action". This is the most basic test we can do on our reducer.
We'll say const initialState = undefined; const action = { type: "" }; const result = productsReducer(initialState, action). Finally, I expect(result).toEqual, and in this case, it's going to equal empty object with the key of products that also has an empty object inside of that.
Save that. Open up the terminal window. We'll type npx jest -- productsSlice. We just want to run the tests associated with this file. You can see that it passed.
For our next test, we're going to start by making a copy of the first one. We'll say it, in this case, it's going to say, "Should convert the products received to an object". To get this to work, we're going to need to import our products from public/products.json.
Those are the mock files that we're using on our server. We'll use them in our tests as well. Here, for our initialState in our test, we'll keep it as undefined. For action, we're going to say productsReceived(products). The result statement's the same.
For our expect statement, this obviously isn't going to work anymore because we expect it to actually have products. We'll say expect(Object.keys(result.products).length) to equal products.length.
This should have the same number of products stored in the resulting state as was found in our initial array. Now let's confirm that all the products have the right information. We'll say, products.forEach.
For each product, we will expect result.products, product.ID to equal the current product that we're looking at. Every single one of the products in our mock products data, the one that we use to power the website, all of those need to exist here in our resulting products in our redux store.
We'll open up command line, rerun those tests, and turns out we need to import received products rather than products received. No big deal. We can change that here. npx jest --productSlice. Both of those pass. Now take a look at what this gives us in terms of our code coverage.
I type npx jest --coverage, and then -- productSlice. We'll see the coverage generated only by testing this file. Open up that coverage report and you can see now that there's a little bit of coverage here in the products folder and that our product slice is actually 100 percent tested.
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!