Handling response codes

- [Instructor] If you follow along so far, we now have a bunch of methods with some similar code for checking response codes. While we could leave these checks in place, it's starting to feel kind of messy and just asking for trouble if we have to make changes or update things later on. So let's dive into one approach for doing this. Let's create another protected function, and we'll call this simply checkResponseCode. And we'll specify one field incoming of expected. And now we have to think about how we've been getting the response codes a date. So we'll say statusCode equals this. We'll get the client that we've been using. We'll get the last response, and then we'll get the status code from that. Now let's make this real simple. So let's say assert expected equals statusCode. And, if that's not true, that means we have an error. So let's go ahead and come up with a very simple error message of Expected, the expected, status code but we got statusCode instead. Quick, sweet, simple to the point. Not a whole lot of complexity here, but now we need to go ahead and we need to embed this throughout the functions that we've used before to make use of this refactoring. So let's go ahead and we'll say checkResponseCode, and let's go ahead and scroll up. We could do this the easy way. Oh, here's one right here. So let's say this checkResponseCode and the only parameter it takes is the expected response code. So now we can simply delete all that. And, even better, we don't need to get the status code up front. We're doing that in the function itself, so we can delete that line too. Now, we could do the same refactoring in other places, so we can get rid of this one where we expected a 201. We can delete this place we are expecting at 201 and just put 201 here. There's a few more places we can do this. Let's see here's another one where we're expecting a 200, so let's go ahead and say 200. And I think, yeah, here's one more. We're pretty close to the end of this. Let's make sure we are expecting the 200 again. All right, and that should be it. So now, if we've done this correctly, we can go back to the command line, run our test, and make sure everything works as before. So let's test that. All right, we run our tests, and it looks like things are working pretty well so far. Hey, that's a good sign. We didn't break anything, or at least we didn't break anything that we found so far. This is always one of the fun things about testing and refactoring. As long as we have good tests, we can have a lot of confidence as we build or refactor things because we know if it worked before and we make a change, it should work after. Unless we made a breaking change, then we have another problem. But now we have one other capability in hands. Let's go back to our editor and look and check and see what we can do. So now we have all these other places. This, for example, I request a list of issues. Now, previously we weren't doing any checks around this. We could go ahead and add this check response code 200 to that almost for free. Now we could just drop that in wherever we need it, and we could apply this check in just about everywhere, quickly, simply, easily, without a whole lot of thought. And, in fact, we could do other refactorings here. I'm not going to go through all of them, but here, this if could just be replaced by an assert. Think of all the things we could do. Look for opportunities to refactor your code and clean things up because not only is it easier to maintain when it's nice and clean and predictable, but it's also easier to update, easier to extend. And generally your tests, when they're easier to maintain, extend, and update, people are going to keep them up to date. And, with that, let's go ahead and dive into how we extend and expand our testing with other external libraries.