Mock API Responses with Swagger
APIs created with Swagger have a built-in mock function, allowing you to mock responses from your API prior to writing the backend code to make it functional. In addition to learning how to enable this feature, I will show you how to write your own functions to enhance the mock responses returned when using the Swagger mock feature.
[00:02] We can use the command Swagger project start with the dash m flag to enable mock mode. When we start that up, or Swagger project is going to start like normal, and then, we can go to a browser and we can open up the API endpoint, and we can see that our get operation has returned a mock response, right?
[00:24] It created a to-do ID, it created sample text and it filled out all the details that were required in our schema definition for a to-do object. The same thing goes if I specify WAC to-do WAC one, it returns a to-do with the ID of number one and this allows you to continue with your testing before you spend the time and energy to write up the back end code.
[00:48] What if you need something a little more complex, right? This sample text isn't going to cut it. In our project folder in the API section, we have this mock subfolder. Here, we can create a new file and I am going to call it get all to-dos.JS.
[01:04] Why did I choose that name? Because over here in our schema definition, when we defined the root in point under that get operation, we specified the X Swagger router controller as get all to-dos, and it's going to look for a function called get all to-dos. This is the reason I'm giving it that name, and then inside, we're going to give it a function with this name.
[01:28] First thing I'm going to do is export that function name, and now, we'll go ahead and create that function. Because this is acting as middleware, we need to specify the request, response and next objects in there. We 're just going to use response.JSON and then our get operation on the root endpoint, returns and array, I'll specify that.
[01:49] Inside of that array, we have our to-do items themselves. I'll specify a to-do ID of zero. I'll create a to-do, sign it via an author, give it a created date with a full timestamp, assign it a due date and mark it as completed of faults. Because it is an array, I can go ahead and specify another to-do, as well.
[02:12] We could go on creating additional to-dos, but I think this gives you an idea, I'm going to save that. If we check back on our console we say that it shows the file changed was our get all to-dos JavaScript script in a mock folder and it restarted the server.
[02:28] Now, if we refresh our root end point, we see the two dues that it created. I was able to write a little bit of JavaScript and change the output of the mock operation. Any JavaScript will work, if you have unique business constraints that you need to mock out, you can do so in that mock folder.
[02:45] Hopefully, it saves you a little bit of time without having to fully implement and wire up the backend.