Mock API integration using Jest

[00:00 - 00:14] In this lesson, we'll be exploring how to mock API integrations in order to add a recipe search to our application. This will allow users to search for recipes using one or more ingredients.

[00:15 - 00:32] Instead of creating a separate logic to store and manage recipes, we can leverage an existing API to extend the functionality of our application. To get started, we'll use Rapid API, an API marketplace with a wide range of APIs.

[00:33 - 00:48] In our case, we'll use the recipe API provided by API Ninja on Rapid API to power a recipe search feature. The first thing we need to do is add another dependency to our application.

[00:49 - 01:02] We'll use Axios to make HTTP requests. So, open the terminal and run this command.

[01:03 - 01:12] First, we need to have our recipes search endpoints, which I've added here, API V1 Recipes. And I'll go into the recipe router.

[01:13 - 01:28] We have defined a route for ingredient. That is API V1 Recipes/A Path variable for ingredient under the recipes path.

[01:29 - 01:34] And here's the controller. This will be the entry point for our recipe search functionality.

[01:35 - 01:53] Next, we need to fetch data from the third-party API service by API Ninja on Rapid API to power our recipe search feature. However, making actual HTTP requests during testing can lead to rich limiting issues and incur costs.

[01:54 - 02:03] But avoid these problems. We'll use just to mock the Axios library, preventing it from sending actual HTTP requests.

[02:04 - 02:09] Here's the webpage for recipe API. What I've done here is to test the API endpoints.

[02:10 - 02:18] And in the query, I entered pasta and I'll go ahead to test it. And here's the response containing a list of different objects.

[02:19 - 02:24] So, I'll go ahead and copy this so that we can use it in our test. Here is the same list in the code editor.

[02:25 - 02:36] This is the same static list that we used in our first basic unit test in module 2. Having created the API endpoint and the controller, I'll go ahead to test this feature to be sure it works.

[02:37 - 02:45] And then we can go ahead to write our tests. In REST API client extension for Visual Studio Code, in here, the method I've selected get.

[02:46 - 02:50] And this is the HTTP endpoints for recipes. I'll search for Carrot.

[02:51 - 02:55] And I'll click the send button to send the HTTP request. And this request was successful.

[02:56 - 03:04] And in the body of the response, we have a list of different recipe objects. I can close this now and let's go to our test.

[03:05 - 03:12] In this unit test, we're mocking the access library using just_smoke function. In one of the previous lessons, we used just_demoke.

[03:13 - 03:18] And in this case, I'm mocking the entire library. As for our test case, I'm sticking with our use naming framework.

[03:19 - 03:24] I've created a describe block here. And this is the name of the unit on the test, gets recipes by ingredient.

[03:25 - 03:40] And in the after each hook of our describe block, I'm calling clear all mocks on the just object. And for our test case, we created the mock response using mock resolve value, which will result to an object that has a key data.

[03:41 - 03:58] And the past our recipe list is the list that I got from Rapid API when I tested the HTTP endpoints. In the act step of our test, we executed the get recipes by ingredient, which is a function that makes the HTTP request to the third party web service.

[03:59 - 04:11] Finally, we are set using expect function and we're checking that the access the requests, which we have mocked, must have been called. Using to have been called means that the mock was called at least once.

[04:12 - 04:20] It is the same thing as using to have been called times. One, if we expect that our mock must have been called twice, we'll simply change this to two.

[04:21 - 04:32] And also another session that we made is to check the recipes that we got from get recipe by ingredient. And we make an assertion that it is equal to the past recipe list.

[04:33 - 04:41] I have saved this past recipe list in the fixtures directory. I'll go ahead and run this test and it should run successfully without failing.

[04:42 - 04:47] And there it is. One other point I want to touch on is that here we use just the mock.

[04:48 - 04:56] We can also use just the spy on dot mock resolve the value, which is what we did here. Mock resolved value by using just the mock.

[04:57 - 05:02] We determined what it will return in here. So this is equivalent to this.

[05:03 - 05:24] But whenever you use a mock, always remember to either reset if you have more than one test in the describe block or you can just easily use just the clear or mocks. Remember, mocking API integrations is a widespread practice in testing as it allows us to avoid retle emitting and potential costs.

[05:25 - 05:34] It also improves the speed and reliability of our tests. You have learned how to mock API integrations to add a recipe search endpoint to your application.

[05:35 - 05:36] See you in the next lesson.