Mock API integration using Nock

[00:00 - 00:58] In this lesson, we will mock API integrations in our application. Similar to the previous lesson, we will write a unit test for the Get Recipe Controller using NOC instead of just the NOC library is a powerful tool in Node.js that allows you to mock HTTP requests and responses or testing purposes. It is HTTP client agnostic, meaning it can work with any HTTP client. It intercepts outgoing HTTP requests and provides a way to define custom responses, enabling you to simulate different scenarios without actually making real network requests. Other tools exist for mocking HTTP requests, such as Axios, M OC adapter, and MOC service workers, which has gained a lot of traction recently. The first thing we need to do is add the NOC dependency to our project. We'll add NOC as a dev dependency.

[00:59 - 02:25] So head over to your terminal and run this command. Let's review our Get Recipe Controller. Like any controller, it's request, the request, and response object. And the Get Recipe Controller, it reads the ingredient from the request parameters and then uses this ingredient to make HTTP requests and fetches all recipes that contains this ingredient. If the HTTP request fails, we'll return the response with status 500. The Get Recipe by ingredient is responsible for making the actual HTTP request. Finally, we'll return the recipes we wrote from the web service as a JSON. Now, let's see how we can unit test this controller. In this unit test, we're mocking the HTTP request using NOC. In the before each hook, we create an interceptor. In the function, I entered the root spot of the API. While using the Get Function, you have to enter the correct path. Or else, NOC will not intercept the request that goes to this path and NOC will throw an error, passing your tests to fail. You will notice an asterisk here, which matches all the path following the recipe. And I also use the dot query function and pass through to it. This matches the URL of the specific API we are using in this application. Finally, we determine the response as it was 200.

[02:26 - 02:45] And in the response body, we are returning past our recipe list as JSON. Similar to just mocks. In the after each and after all, we use the NOC.Clean and NOC.Restore and NOC.Clean here.

[02:46 - 02:59] In our test case, following unit test practices, we created MOC request and MOC response. For the MOC response, it is an object that contains two keys, status and JSON.

[03:01 - 04:46] For status, it is a stop which returns another object. And in the inner object, we have JSON, which is also a stop. You will notice the use of MOC return value as against what we have used so far, which is MOC resolved value. The difference between both is that MOC return value returns this and MOC resolved value imitates an asynchronous function that resolves into that value. This is the orange step of our test case. In the add step, we execute getRec ipesController function, passing into the MOC request and MOC response. And in the set step of our test case, we are set that our JSON stop in MOC response must have been called. We also are set that the JSON stop in our MOC response was called with past our recipe list. So you might ask, why do we have JSON in status and JSON here? Let's review the controller function again. Over here, if an error occurs while we make an HTTP request, we return status with 500. If the HTTP request is successful, we use JSON in our response object. So that is why we have JSON over here and in the status stop also. With this, we can test our code without making actual HTTP requests similar to the test we wrote in the previous lesson. I'll go ahead and run this test and issue run successfully without showing any error. There you have it. We've written a unit test for our controller function that makes HTTP requests to a third party web service.