1. 6
    Adding More Test Cases for a Redux Reducer
    2m 21s

Adding More Test Cases for a Redux Reducer

Jamund Ferguson
InstructorJamund Ferguson
Share this video with your friends

Social Share Links

Send Tweet
Published 3 years ago
Updated 2 years ago

Just because you've run a function through one set of inputs, doesn't mean other inputs will behave the same way. This is often true with state management solutions where it's common to memoize responses & cache data. We only end up with 4 tests total for our products reducer, but I'd like you to consider all of the following cases when you're writing reducer tests for your production applications.

  • Valid Input
  • Valid Input more than once
  • Invalid Input
  • Invalid Input more than once
  • With Existing State
  • With No Existing State
  • Invalid/Unknown Action Type

Instructor: Even though Jest says that our reducer method has 100 percent test coverage, we're actually not testing every possible scenario yet. There are actually at least two additional cases that we really need to check.

Go back into your test and type, "it should not allow same product to be added more than once." Here, I'm going to start with the previous test as my base. I'm going to go ahead and add in all of the products and then I'm going to try to add them again.

We're going to do that by changing const to let. Then we'll say at the end here result = products reducer result, action. We're going to rerun the products reducer with the output of the last run of products reducer and then save that output to result.

What we want to see is exactly six items and no more than that. Let's go ahead and run it and see what happens.

Npx jest --product slice, and we're passed. For our next test, let's just copy this one. We'll say, our products reducer should allow multiple products to be received at different times.

We're going to use the same formula as last time, except when we pass in the products that we want received, we're only going to pass in part of the products in our array. We'll say products.slice 02.

Then we need a new action because we're going to pass in for the second action a different set of products. We'll say const second action = received products, and we'll say products.slice from two to four, which should give us a different set than the first set did.

Then we can say, result = products reducer results second action. We'll expect here that they'll be four items now in our cart. Back in the terminal, we run our tests and indeed it passed as expected.

Just a reminder, even though your code coverage looks really good, there are always more cases that you need to test. Don't just give up at 100 percent coverage. Think about the cases that your actual application might expect or maybe shouldn't expect to receive.

egghead
egghead
~ an hour ago

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

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

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!

Markdown supported.
Become a member to join the discussionEnroll Today