Current section: HTTP Mocking 5 exercises

Testing Error Handling and Assertions with Mock API Calls

Loading solution


00:00 We borrowed a lot of stuff from the previous test. This should look kind of familiar. We're gonna make a utility out of this a little bit later. But we want things to behave a little differently now. So instead of sending users off to onboarding, we want them to go to login. So let's add that assertion here so we get our test failing first.

00:17 So assert redirect, the response should go to login. Now that response is gonna come from this. And I happen to know also that when there's an error, we throw a response object. And so we could do a try catch around this. I don't like doing that. So we're gonna actually just do a catch.

00:35 And we're gonna take the response and return that response. So that turns that thrown response into just a resolved response. Now we're getting a failure because that response is actually redirecting to onboarding instead of login. And so we want to make sure

00:51 that that is not happening that way. We also have this assert toast sent. So we wanna have that assertion as well, or that Kelly put together for us. So that is just making sure that our EN toast is gonna be sent. And I should mention also, these assertions are not the best

01:11 and we will have custom assertions next or a little bit later. So let's assert the toast was sent on that response. And then we also want to make sure that the console error was called as well because we do log an error when that happens. So let's bring in console error.

01:30 And because we're doing that, we're gonna have to add console error dot mock implementation and that way we don't get the throw from when that happens. So there you go. We've got all of our assertions set up. We're in a good place now. And so now we just need to make sure

01:49 that we set things up so that this does in fact fail in the way that it's supposed to. So right here, we're gonna say, let's get rid of that as well. We're gonna say server, which is coming from our mocks dot use.

02:07 And this is an HTTP post that's coming from MSW. And we pass the access token endpoint, which is right here. So we're gonna override that handler for this particular endpoint. And this is gonna take a request. And with that request then, actually we can ignore the request.

02:31 And in our case, we don't care about the request. We're just gonna send back a failure. And so here we'll say, return new response error status 400. So some kind of error. That's all we're testing is what happens if there's an error. So I save that and we should get a passing test. We do, awesome.

02:50 So the error case is being taken as a part of this flow. When the access token endpoint returns an error, then we throw the redirect response as we put together in the auth workshop. And then we're handling all of that here.

03:07 Now, we are making a mess of the world with this server dot use. We need to clean up after ourselves. And so we're gonna add an after each from the test. And this is just going to call server dot reset handlers. And what that will do, we gotta spell it right. There we go.

03:26 What that's gonna do is ensure that when you start up your server at first here, you provide some handlers. And then all of the handlers you add with server dot use like this are kind of like secondary handlers. They actually will come first. So if they match, then they'll be the ones that are called.

03:46 And then the existing handlers will get called thereafter if need be. But between these tests, we're going to say, hey, reset the handlers to get rid of those ones that were added with server dot use. And we'll just use the ones that were initialized. So that's what reset handlers is doing for us. And we want that between every test

04:06 so that we keep our tests isolated. Anytime you mess up the world, you wanna make sure you're thinking about how to clean it up again. That's a lesson for life. So let's talk really quickly about what we did here. First, we updated this to handle the fact that we're throwing a response in this error case. So we catch that.

04:25 And then we're asserting the redirect went to login because the auth flow failed. The toast is going to be sent to explain what went wrong. We're gonna improve this later. And then we expect the console error should have been called at least once or exactly one time.

04:44 And then we turned on this mock implementation because if we don't, then our original mock implementation is gonna throw an error and say, hey, you ended up calling console dot error. And here it is actual, let's see. It's gonna be in here somewhere where we're, oh, actually, no, that's failing for another reason altogether anyway.

05:05 So yeah, you definitely wanna have this mock implementation so we don't log that error. And that takes care of the setup for our test. And then finally, we need to do the pre-setup for the server to make sure that we're overriding

05:22 the access token HTTP post endpoint so that when the request comes in, we actually make it fail and then we can test the failure case in this case. And then finally, we want to restore the balance in the force. We want to restore things to their natural order

05:41 having the happy path implemented in our GitHub API mocks. And so we say reset handlers back to the happy path. And that is overriding mocks with MSW.