8.10 Unit Testing HTTP Interceptors

Hi folks, in this lesson we're going to see how we can unit test HTTP interceptors. These might seem quite complex and hard to test. But like services, pipes, and a number of other Angular constructs, really they're just classes. When we created the HTTP interceptor that the application uses, we created it manually, so we don't have a spec file yet. First of all, we'll need to create the spec file manually. We can then get it side by side with the actual interceptor. So, first of all, we'll need to import the interceptor so that we can test it. And we will also want to bring the HttpRequest class from Angular. So now we can get started with the test. Let's add the outer describe, first of all. And we'll fdescribe it so that only these tests will run. So, first of all, we'll need to create a new instance of the interceptor. So now we can use the interceptor instance in the interceptor variable to perform our tests. So now let's add an it method. Let's think about what the test is going to do. So the code adds an x requested with header to the request. So we want to check that, that header does get added. So our interceptor is pretty straightforward, it just adds a single header to the request. So we should need to only add this one test for it. So, first, let's create a variable to store the modified request in. A create a fake request and a fake next method to pass to the interceptor. The fakeRequest needs to be an instance of Angular's HttpRequest class because there are some methods that we'll want to make us of with our assertions. We'll come onto these in just a moment. The fakeNext variable that we've created is just an object that has a handle method. This is just like the next that gets passed into the intercept method when Angular invokes our HTTP interceptor. And we use Jasmine's createSpy method once again to create a spy. And this time we want to call a fake function. And that fake function will get called and passed the request. And we want to save that request in the modified request variable that we created right at the start. So now we can invoke the interceptor and make some assertions So all interceptors have an intercept method. And the request and next objects get passed to this. So when we invoke the intercept method, we can pass in our fakeRequest and fakeNext objects that we created. So now let's make some assertions. So, first, we can just check that the handle method of the object that we passed in for the next parameter does get called. So next, we want to check that the modified request object does have a header called X-Requested-With. And we can use the has method of the header's object within the modified request, which Angular will add. That's why the fakeRequest need to be an actual HTTP request and not just some fake object that we create ourselves. And lastly, we just want to check that the value of the X-Requested-With header is the value that we expect. And this time we use the GET method of the header's object to actually get the value of the header. And actually, on that second assertion, we need to check that the has method returns true. Okay, so let's go back to the browser now. And we can see that the last expectation is failing because it's actually Angular woot with an exclamation mark, rather than just Angular woot. And the test now passes. So, in this lesson we saw how easy it is to write unit test for an HTTP interceptor. We saw that as all interceptors have an intercept method, we just need to create an instance of the interceptor. And we can then invoke this intercept method in order to test what it does. We also saw how we can fake the different arguments that the intercept method expects. And how to test the request has been modified in the correct way. Thanks for watching.