Be agile with mock-servers

When engaging in a full-stack web project, quite often one of the main delivery goals is to allow front-end developers to create features and quality engineers to write tests without needing the back-end implementation to be fully ready.

A common method to achieve this goal is to add a mock-server that behaves like the back-end. By definition, a mock-server allows easy mocking of any system you interact with via HTTP or HTTPS. I’ve found them extremely helpful and use them in every full-stack project I’m involved with.

Benefits of using a mock-server

Using a mock-server helps to decouple teams and simplifies testing, leading to higher velocity within sprints and more control over testing scenarios and data.

While it is possible to coordinate between the front-end and back-end, it can be very challenging. Besides, we all know coordination and timing doesn’t always align. A mock-server can act as a contract for each team, with expectations set on both sides. A typical workflow can be:

• Back-end team identifies a contract
• Back-end and front-end teams begin work at the same time
• Front-end team updates mock-server to match the contract
• Front-end team tests their implementation against the mock-server
• Once back-end is ready, front-end team integrates with the real API and tests against it in a shared environment or locally

Each team has a clear path forward and can iterate at their own speed. If a missed scenario is identified, the front-end team can continue by updating the mock-server while the back-end team makes their modifications.

With a mock-server, testing happens early, meaning bugs can be found and fixed early in the SDLC. It’s also easier to make updates to a mock-server to cover various testing scenarios. The mock-server can be added to the CI pipeline, leading to potentially faster pipelines and continuous testing of a larger set of cases.

You can tweak the workflow in any way that fits the team. A mock-server gives you a tonne of flexibility and agility.

Integrating a mock-server – quick tips

There are many ready to use mock-servers for almost any type of project and technology. Some I’ve worked with recently include mock-server, json-server, and Apollo Server’s mock-server feature (for GraphQL). No need to re-invent the wheel, try to find one that is readily available.

Place it close to the front-end

House the mock-server in the same repository as the front-end, within its own folder, since it’ll be used primarily by the front-end team. This simplifies your setup and allows all mock data and APIs to be easily referenced. If your mock-server implementation becomes large, you can always move it out and integrate it as an external dependency.

Include it in your solution spin-up

Including the mock-server as part of your solution spin-up is extremely useful. This means when you spin-up your product locally, or in a CI/CD pipeline that runs tests, the application and mock-server can be run and interact with each other. For example, if you are using Docker containers, include the mock-server within your Docker Compose setup.

Add a mechanism to switch between the mock-server and the real back-end

Add a mechanism to switch between connecting to the mock-server and the real back-end. This will help when integrating with the real back-end and testing the connection, or when switching between UI and integration tests.

Gotchas

While there are many benefits of using a mock-server, it is technically “extra work”. There is an initial setup and additions or updates need to happen throughout. With the right tools and process however, I believe it’s a negligible downside compared to the benefits.

Another gotcha is there might be a mismatch between the real API and the mock-server. While there are clever ways around this, it can be time consuming and tedious. Most often than not, it’s ok if there are minor differences. I’m yet to find a suitable resolution for this gotcha.

Lastly, if you look back at the workflow above you’ll realize the last point, integrating the front-end with the real API and testing against it, needs to be tracked as an extra task. Not a significant effort, but worth noting as it’s an important step to ensuring the front-end works with the real back-end.