Join egghead, unlock knowledge.

Want more egghead?

This lesson is for members. Join us? Get access to all 3,000+ tutorials + a community with expert developers around the world.

Unlock This Lesson
1×
Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.

Autoplay

    Simulate network errors within tests

    Shane OsbourneShane Osbourne
    redux-observableredux-observable

    Handling errors correctly in an application can be one of the most important parts of any project - it’s crucial to get it right and therefor it warrants having unit tests covering it. Again, because we’re using the power of Rx, this is an extremely straightforward task.

    Code

    Code

    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson
    Discuss

    Discuss

    Transcript

    Transcript

    Instructor: We have a test here for an application, but it's really only exercising a single happy path. We are stubbing the getJSON method and returning a simple piece of data. If we look inside the epic, that means that this part always returns some data, which means we'll end up here. We never, ever get inside this catchError.

    It's extremely important that this catchError function exists. Should an error message occur, we need to ensure that we catch that error so that we can show a nice message to the user. Let's return an empty observable here, just to prove that our test will still pass. If an error did occur inside the application now, the user would never know about it.

    Let's write a test to handle this case. Let's rename this one to say that this handles the success case. We're just going to copy/paste for now. Of course, you can abstract this into some test helpers if you'd like. We're going to deal with the error case.

    It says we have two passed, two in total. The action will stay the same. The state stays the same. The thing we're going to change here is that we're not going to produce an element here. We are instead going to throw an error. The way we do that is we give a hash sign. We remove the values. We can just give that as null. The third argument here will be the value of the error.

    We happen to know that should the AJAX request produce an error, it'll have a response key. We know that the API we're dealing with has a message. We can just say, "Oops." That will simulate an error in this getJSON method.

    We should assert what we expect. We would still expect to go into a pending state first. Here, we would expect a failure. We'll import the fetch failed action creator. Looking at its signature, we just send through a message. It's going to be the same message as this.

    That's what we expect. We still get the failure here, just how we wanted it to be. This failure in particular is showing us that we only have one item produced. We expected two. Go back to our epic and undo that. Now you can see it passes.