Fake it till you make it: mocks for agile development

What is agile development? Agile software development is the practice of providing continuous feedback to iteratively refine software, following the core values outlined in the seminal Agile Manifesto.

Agile methodologies focus on continuous planning, continuous testing, and continuous integration, while empowering people to collaborate and make decisions quickly and effectively. In this manner, teams can adapt quickly to a changing landscape with mid-stream feedback and insights.

How are mocks used in agile development?

Delays on the front- or back-end make it difficult for dependent teams to complete their work efficiently. Mock servers can alleviate those delays in the agile development workflow.

A Postman mock server lets you mock a server response, allowing a team to develop or write tests against a service that is not yet complete or is unstable. The mock endpoint running on Postman servers will return a saved response, simulating the function of your real service, until a time when your real service is delivered.

Essentially, mocks help you fake it till you make it. By faking real endpoints, mocks are used at various stages of the agile development process.

Continuous planning

Mocks are used during the earliest stages of planning to prototype a new idea. For example, the mobile or front-end developer creates a mock for the platform team to indicate what kind of server response is needed to support the user interface they’re working on. Another example, the technical architect or product manager gets a head start on drafting a mock for the user story they’re envisioning.

This prototype kicks off the planning process by providing a starting point for the discussion, and there’s little technical overhead with this type of approach. You can spin up a mock with a few clicks, without ever opening your integrated development environment (IDE) to trudge through the existing code base or deploying a single line of code.

Continuous development

Once the requirements have been agreed upon, the mock responses will inform an agile team’s Definition of Done (DoD), the benchmark used to assess when a user story has been completed to the team’s satisfaction. Mocks can be incorporated into the specifications document that the team begins working toward. The team relies on the mock to visualize the intended server response to begin both development and testing, in parallel.

With the traditional waterfall development process, testing begins once development is complete. Teams transitioning to a more agile process are sometimes perplexed as to how both development and testing can be completed in a short 2 to 4 week sprint cycle.

With agile development, testers are involved throughout every stage of development. By emulating a service that is under development or unavailable, the tester can begin writing unit tests against the planned API as soon as the specifications are agreed upon.

Continuous testing

In today’s ever-growing ecosystem of relying on internal and external services, the dependencies can grow in complexity. Automating test scenarios that rely on mocks to encapsulate the system being tested is particularly helpful in detecting defects early and providing rapid feedback for a team that practices Continuous Integration (CI), merging code as frequently as several times a day.

Unit tests can be written and executed against mock responses when testing parts of the application that connect to backend services. QA engineers can also simplify integration testing by mocking external dependencies.

Knowing what a server response will be allows a tester to isolate the system under test. For example, when testing something that has dependencies like an identity verification service, you can mock the response from that third-party service knowing that any failures resulting from a test must be attributed to the system under test.

The common thread across all stages of the agile development process is that teams are using mocks to decouple the development process, empowering people to work independently and in parallel.

Let’s learn more about creating mocks in Postman.

Creating a mock response in Postman

We know that we can use Postman to quickly spin up a mock server. In other blog posts, we’ve seen how you can mock responses in Postman by using examples and collaborate with your team using mock servers.

If you’re relying on hosting your own mock servers, that entails lugging out your IDE, updating the code, pushing your code, and then deploying it to the appropriate server environment. On the other hand, you can create a live mock in Postman with just a few clicks. Postman creates the endpoint, deploys it to a live server, and you’re ready to go.

If you don’t know how to set that up in Postman, check out this video.

Dynamically updating a mock response

Let’s agree to agree that it’s super easy to spin up a mock that returns a fixed response. A couple clicks to set up the mock server. A couple more clicks if you want to add or update the mock response. It’s easy to update examples in the Postman UI.

However, besides generating just a static response, some teams want to dynamically update a mock response.

Let’s walk through more possibilities for updating a mock:

1. Create a mock from scratch
2. Add a new mock response to an existing collection
3. Generate a new mock response for an existing collection
4. Update a mock response for an existing collection
5. Transfer value from request to response
6. Return a response based on the request
7. And more

Want to follow along in the Postman app? Click the orange “Run in Postman” button below to download the Postman collection and environment containing these sample requests, or check out the documentation.

click this button to download the collection and environment

#1 Create a mock from scratch

In Postman, a mock is essentially a paired request and response saved to a Postman collection. So it makes sense that we would first need to create a collection if we don’t have one already. Let’s use the Postman API to create a new collection, and then create a new mock associated with that collection.

Requirements

• Postman API Key

Workflow

1. Use the Postman API to POST a new collection
2. Use the Postman API to POST a mock

#2 Add a mock response to an existing collection

Now say we already have a collection, and we want to add a mock to our collection. Same as the previous scenario, but we’ll need our collection_uid first.

Requirements

• Postman API Key
• collection_uid

Workflow

1. Use Postman API to GET a single collection
2. Add a mock example to the collection (via Postman script)
3. Use Postman API to PUT a collection

• Note: if exporting the Postman Collection (version 2.1) from the Postman app and there are no headers, verify that the collection’s response headers are equal to [] (empty array, instead of null).

#3 Generate a new mock response for an existing collection

This is the same as the previous “Add a mock to an existing collection” scenario, except you can generate or retrieve information to update the mock example.

Workflow

1. Use Postman API to GET a single collection
2. Perform calculations or generate data (via script)
3. Use Postman API to PUT a collection

• Note: if exporting the Postman Collection (version 2.1) from the Postman app and there are no headers, verify that the collection’s response headers are equal to [] (empty array, instead of null).

#4 Update a mock response for an existing collection

This is the same as the “Add a mock to an existing collection” scenario, except you will first search for an existing mock example to replace.

Workflow

1. Use Postman API to GET a single collection
2. Find and update mock example in collection json (via Postman script)
3. Use Postman API to PUT a collection

• Note: if exporting the Postman Collection (version 2.1) from the Postman app and there are no headers, verify that the collection’s response headers are equal to [] (empty array, instead of null).

#5 Transfer value from request to response

This is the same as the “Generate a new mock for an existing collection” scenario, except you can enter data in a Postman request that will execute before this request to update the mock example (instead of entering data in the environment variable editor).

Workflow

1. Use Postman API to GET a single collection
2. Retrieve data, for example from a POST request to sample Echo collection. You can also utilize a previous request to another endpoint or retrieve data via a Postman script like pm.sendRequest().
3. Use Postman API to PUT a collection

• Note: if exporting the Postman Collection (version 2.1) from the Postman app and there are no headers, verify that the collection’s response headers are equal to [] (empty array, instead of null).

#6 Return a response based on the request

If you have a number of examples saved to a Postman mock, the Postman matching algorithm has a predictable way to retrieve the desired response. You can do this either in the Postman app or with code.

Configurable elements to retrieve a response:

• Request method — any valid HTTP request method of a saved example (e.g. GET, POST, PUT, PATCH, DELETE, etc.) to select as part of your request
• Request path — any valid string path of a saved example (e.g. /, /test, /test/path, /test/path/1) to include as part of your request URL
• x-mock-response-name — optional header with the name of a saved example
• x-mock-response-id — optional header with the uid of a saved example

#7 Other ways to programmatically update mocks

In the same manner we’ve demonstrated here, you can update mocks after accessing your local file system, pulling a response from a REST-enabled database, and so on.

Final thoughts to let Postman mock your world 🌎

Now that we’ve opened the door to the endless possibilities of mocking, let’s keep an eye on the reason why we’re diving deeper. We’ve talked about how mocks are used at various stages of agile development.

• Continuous planning
• Continuous development
• Continuous testing

For agile development teams, mocks can offer many ways to iterate rapidly by allowing team members to communicate expectations, decouple dependencies on other teams and services, and identify defects more quickly using less resources.