In this chapter, we're going to be talking about Mocking.
Mocking is basically faking, pretending, and there are many reasons that we testers might want to take advantage of this feature against APIs in Postman.
There are three main ways mocks can be created in Postman:
You can create a mock server that's based on a specification file. This is a really great option if you have the right documentation at hand, which details the API.
You can create a mock server from scratch, adding in requests and telling Postman what response data to return.
You can add a mock server to an existing Postman collection.
For example, if we wanted to, we could add a mock server to our Restful Booker BVT collection.
We might do this to detail some example responses our APIs could come back with, so that we can use those in our testing.
Let's go ahead and do that, shall we?
Where do we go to create a new mock for an existing collection?
Let's open Restful Booker BVT and on the ellipsis menu here, we can click the "Mock collection" option.
This takes us to the "Create a mock server" tab, where we can either select a collection to mock or as we've already selected our collection before creating this, we can enter the configuration details of the mock server we want to create.
For simplicity, I'm just going to call it "Restful Booker BVT Mock".
Postman already knows we want to add this to the Restful Booker BVT collection and we select our "CURRENT" version because that's the only version we're using currently.
In terms of the environment, we would like to select "No Environment" and keep the option "Save the mock server URL as an environment variable" ticked because what this will do is create a new environment and add the mock server into that new environment, mapping that URL.
We don't need to make the mock server private because we're using a public cloud-based mock server, but if you did need to make this private, for whatever reason, you can go ahead and then use an
x-api-key header to your request to make that work.
Click "Create Mock Server" and here is your URL detailing your mock server.
The next thing we want to do is go ahead, and we can see here, we now have a new environment, "Restful Booker BVT Mock", and that mock server URL has been pasted for us into a variable called
However, let's quickly rename that variable to
rb_url to match that of the production environment.
This will just allow us to switch between those environment variables a lot easier.
rb_url variable into the "Restful Booker Mock", click "Save" and then if we return to "Collections", what we'd like to do is for the
POST request, we'd like to use our mock server in there.
We can see when we're running that request against the production environment, that generates a token for us and a status of
But in order to use the mock server, we need to press the ellipsis menu against the POST Auth and add an example.
We can see here there is no status code mapped, but Postman has created an example underneath the POST request that we can then customize with anything we want our mock to return.
We can copy and paste the response body, the
token in there If we wish, we can change the status code or we can even change the body of the post request if we wish to.
For now, let's insert the
token body, copy the body from the successful POST request into the example request.
We're going to change the status code to be "400 Bad Request".
We want a negative test case to accompany our positive one in the production environment.
Going back to our original request that generates our "200 OK" message, if we change the environment to be the "Restful Booker BVT Mock" that we've created, and we re-run exactly the same POST request, it's going to be looking for this example that we've created.
I'd expect instead of returning a
200 OK status, it's going to return the 400 Bad Request.
That's exactly what happened, so we now have a negative response there that is generated for us.
What if you want to add some more examples?
Let's go ahead and click the ellipsis menu next to our example and click "Duplicate".
This generates an exact copy of that example.
Let's change the name to "Auth Token Missing" this time, because I want to illustrate what we can do to generate multiple examples for the same endpoint.
If we remove the
token and click "Save", this is going to tell you what happens when the auth token is missing, but how do we tell Postman what example of these two to return?
We can do that by adding in a header to our POST request - the key is
x-mock-response-name and the value is the name of the example, in this case "Auth Token Missing".
That POST request will tell us exactly what we need to do there.
And hurray, we can see that this has correctly returned the missing request token.
So it's found the right example and it's used that
x-mock-response-name header to return the example that we wanted.
This is a really great way to map examples that you want that mock server to return.