One of the biggest challenges in agile development is enabling dependent teams to work independently. For instance, how do you keep your quality assurance teams busy while the backend is still being built?

Joyce Lin, a Developer Advocate at Postman, says that mock servers can help. In this guide to using mock servers for agile development, we’ll walk you through exactly how mocks can be implemented in the three stages of an agile, iterative development cycle.

What are Mock Servers?

Mock servers are used to emulate the responses of a real server. Indeed, mock servers are themselves real servers, but they don’t have full functionality and aren’t usually yours. That means developers don’t have to code them, deploy them, or fuss with any infrastructure. Instead, you can quickly set them up and use them to test your other code, where they can play the role of an unfinished dependency.

Joyce says you have three options when it comes to mock servers:

1. Develop and deploy your own mock servers
2. Use a free or paid service to create and host mock responses
3. Not use mock servers at all

Mock Servers in Agile Development

Mock servers are ideal for agile development since they can be used to decouple the development process, thereby allowing dependent teams to work independently of and in parallel to one another.

A big part of agile methodology is the idea of a continuous development cycle, which is an iterative loop of continuous planning, continuous development, and continuous testing. Mock servers can prove helpful at each stage of the cycle, says Joyce.

Continuous Planning

During the earliest stages of the development cycle — planning — mock servers can be a great way to prototype new APIs or services. By creating a mock server, you can quickly and easily show others how a product will behave. The mock can then become a starting point for discussion, as all sorts of stakeholders are able to get involved and provide concrete feedback on how the API or service should work.

Also, mocks can be used to set clear expectations for dependent teams. For instance, a frontend developer can draft a mock server to communicate what kind of responses they need from the backend, with minimal technical overhead. In using this approach, there’s very little ambiguity in what backend developers need to build.

Continuous Development

Once there’s a consensus on what’s being developed, you can use your prototype mock server as part of the specification that development teams are building towards. What’s more, you can allow quality assurance teams to build their tests against the mock servers. That way, as soon as the real API or service is complete, tests can be rolled out immediately.

Let’s refer back to that example of the frontend developer who used a mock server to define the backend requirements. Now, during this development phase, the mock server’s role is twofold: not only does it tell backend developers what to build, but it also enables the frontend developer to work independently — knowing that the “real” backend will behave just like the mock server. This is parallel development at its finest!

Continuous Testing

After services have been pushed to production, mock servers can help isolate your systems during testing. By mocking both internal and external dependencies, you can be sure that tests evaluate what you’ve been building, and not anything else. Joyce says this allows you to detect any issues a little earlier, thereby speeding up the entire development cycle.

You can also use mock servers to simulate edge cases. For example, if you’re using a rate-limited API and don’t want to incur errors in production, you can simulate the API’s behavior using a mock server.

Mock Servers at Postman (Case Study)

Postman offers a proprietary solution for setting up mock servers, which they themselves use as part of their internal development process. Joyce walks us through the steps of doing so.

Initializing the mock servers is simpler than you’d think. The service owner creates a Postman workspace for their new service. Then, they build collections — in other words, specifications for how the API will behave — which can be used to spin up mock servers at the push of a button.

Postman enables developers to easily set up a mock server.

These mock servers can provide all the benefits we described earlier: easy negotiation between stakeholders, clear expectations, decoupled development, and more. However, Postman is big on consumer-driven contract (CDC) testing, and they find mock servers particularly useful for this purpose.

Consumer-driven contract testing is straightforward: the service provider creates a blueprint which tells consumers “This is how you should use my API.” Then, consumers say “Great, this is how I’m going to be using your API,” documenting how they actually use various resources and what kind of responses they expect to get.

This way, service providers can be sure they meet the expectations of consumers and don’t accidentally break their integrations when the service is finally pushed to production.

In Postman, collaborators can write their own contract tests directly within the workspace. Then, Postman can automatically run services against these contract tests before pushing them forward.

Final Thoughts

Overall, mock servers can be a really handy tool in agile development. Throughout the three stages of iterative design — planning, development, and testing — mock servers prove incredibly useful. During planning, mock servers allow you to draft up new APIs and services, inviting feedback and setting clear expectations for dependent teams. In development, mock servers facilitate parallel collaboration, allowing teams (especially quality assurance teams) to work independently of one another. Finally, in testing, mock servers allow you to hone in on testing your own systems, by excluding dependencies.