Postman Mock Server vs. WireMock Cloud (formerly MockLab)

Postman is indisputably the dominant HTTP testing tool on the market today, and if you’re involved in developing or testing APIs it’s highly likely you’ve used it (or know someone who does at least).

A feature of Postman is “mock servers”, which allows mock APIs to be generated from from Collections (Postman’s main data model - sets of request and response examples). This article compares Postman’s capabilities and approach to API mocking with WireMock Cloud (the new MockLab), examining the relative strengths and best use of each.

Terminology

The concepts underlying Postman’s and WireMock Cloud's mocking capabilities are very similar, but some naming and terminology differs. The following table describes both products’ terms for each major concept:

• In WireMock, a mock API is a container for stubs/examples, accessed via a unique domain name. In Postman, this is called a mock server.
• In WireMock, a stub is a specification of a request to be matched, paired with the response to be returned. In Postman, this is called an example.
• In WIreMock, Response Templating refers to responses that contain random values, variables or request data. In Postman, this is called Dynamic Responses.

Getting up and running

With both products you need to sign-up/log into a user account in order to create a mock API/server.

In Postman you create a mock server either via the context menu for a collection, or from the Mock Servers tab:

In WireMock Cloud, you can create a new mock API via the “+ Mock API” button on the top bar:

Base URLs and domain names

To use a mock server/API in either product, a unique base URL is needed.

Postman will generate a unique domain name for a mock server using a UUID for the hostname e.g.

WireMock Cloud will also generate a unique domain name, using a short hash for the hostname e.g.

WireMock Cloud also permits you to optionally choose a hostname of your own, so you can create a mock API with a base URL like

Importing from other formats

There are a number of widely used formats for describing HTTP interfaces and events. If you’re already working with one of these, being able to generate a mock API automatically from it can be a big time-saver.

Postman can import from OpenAPI, RAML, GraphQL, curl and WADL:

WireMock Cloud supports OpenAPI, Swagger, Postman collections and WireMock JSON:

Customising the import

When importing from a specification format like OpenAPI (one that represents a contract rather than just a list of request/response pairs) it’s useful to be able to exert some control over how your examples or stubs are generated.

Postman presents a number of options prior to executing the import that permit you to choose things like whether response examples or schemas will be used to generate the request and response parameters in your Postman examples:

WireMock Cloud takes a slightly different approach. Rather than offering a set of options up-front, it understands a set of extended attributes that you can add to your OpenAPI spec. These allow you to set specific request parameters in the generated stubs, rather than getting the randomly generated defaults. In this way you can also control how randomly-generated values are produced when response bodies are generated from schemas.

schema:
  type: string
  x-faker: name.first_name

See the Swagger documentation for details on using extended attributes.

Dynamic responses

A basic stub or example will return a fixed response each time it is matched. However, in some cases it’s necessary to generate the response dynamically.

Reasons for this include:

• Copying data into the response from the request e.g a URL path parameter or element from the request body.
• Including random data such as names, dates, job titles, addresses etc.
• Generating values that must be calculated per request e.g. when a cryptographic signature must be included.

Postman supports a rich set of random value generators based on Faker.

You can include tokens like {{$randomFirstName}} in an example’s response body and they will be substitued with a random value of the type specified when the response is served. You can find the full list of available tokens here.

Postman also supports using wildcards as variables in response bodies, so for instance if your example’s URL is /v1/users/{{user_id}} then you can return the value of user_id in your response body by including /v1/users/{{user_id}} .

WireMock Cloud supports full Handlebars template syntax in its response bodies and headers. This enables conditional logic and looping, variables, and access to a library of functions via Handlebars helpers.

The model provided to the template includes all attributes of the incoming request, so it’s possible to include URL path elements, query parameters, header and the request body in your responses.

Additionally, there are a number of Handlebars helpers to extract and transform text/JSON/XML, manipulate dates/times, generate random strings (the full Faker set isn’t supported yet) and generate properly constructed, signed JSON Web Tokens (JWTs).

Response delays

Mock servers often return responses faster than their real API counterparts. This is great when you just want your functional test suite to run as fast as possible, but if you’re testing your app’s UX with realistic timings, or want to check that a timeout is configured correctly then you need to be able to add artificial delay to your responses.

Postman permits you to specify a fixed delay at the mock server level.

WireMock Cloud supports fixed, random and chunked delays at the individual stub level.

Automation

In modern development and testing workflows it’s common to want to automate the setup of your environment and to be able to operate your tools programmatically. Both products provide APIs for these purposes.

Postman’s API supports create/update/delete of mock servers and collections, allowing you to automatically configure the mock servers available to your environment and the specific examples served by them.

WireMock Cloud's Provisioning API allows mock APIs to be created and deleted.

Once created a mock API has its own Mocking API which supports create/update/delete of stubs, querying of the request log and control of other features such as recording.

‍

Other features

WireMock Cloud provides a few extra capabilities that are not yet supported by Postman.

Recording - the ability to intercept HTTP traffic between your app (or a client tool) and an API, converting it into a set of stubs.

Proxying - conditionally forwarding requests to another API. This is useful when you want to test against a real API, but mock the parts of it that haven’t yet been implemented. It’s also a good way to reliably return otherwise hard-to-reproduce errors.

Faults - a WireMock Cloud stub can respond with a number of network faults including dropped connections and garbage HTTP content.

Performance testing - Mock servers in Postman are rate limited, meaning they’re not practical for use in a load test. WireMock Cloud's Performance plans provide dedicated host capacity, no rate limiting and a performance metrics dashboard.

Conclusion

Postman mock servers are a great solution if you already have Postman in your workflow, your request matching requirements are simple and you want a straightforward solution that’s tightly integrated with your existing setup.

WireMock Cloud may be the best choice if you need fine control over how requests are matched, advanced response templating, recording, proxying, a comprehensive API or support for performance testing.

And remember, you can import your Postman collections into WireMock Cloud to get started.

If you've made it this far there's a good chance you're building a system that relies on 3rd party APIs. WireMock Cloud can help you test your system when those APIs don't exist yet, have flakey test environments or are expensive to call.

It's quick and simple to get started with and it's powered by open source WireMock so it has the flexibility to grow with your project's testing demands.
Learn more

Get started for free

‍