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?
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.
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.
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.
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.
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.
Hopefully, it saves you a little bit of time without having to fully implement and wire up the backend.