Comparing Prism, Hoverfly, and HMT - Part 2
18th Feb 2020
This is the second article of a two-part series comparing Prism, Hoverfly, and HMT. This article focuses on using all three tools to build a mock of the github API v3, whereas the first article focuses on a high level comparison of the tools.
Team HMT busy building HMT.
In the previous article, we saw how to create a Prism server from an OpenAPI spec. We also saw how Hoverfly can play back recordings of server traffic. Lastly, we saw how HMT blends OpenAPI specs and recordings into a mock server.
In this article, we will examine how all three tools can mock the Stripe API.
To mock the Stripe API with Prism, we first download the Stripe V3 OpenAPI spec.
Then, we spin up a Prism server that will mock the Stripe API according to the spec.
Let's inspect the API using some common Stripe endpoints. For example, we can get test the balance endpoint by calling
Prism provides useful information in the console as it validates the URI.
Unfortunately, this is where I ran into difficulties, as Prism serves the response.
While Prism is good at mocking most API specs, it struggled when it ran into the Stripe spec. I'm sure the team will fix this in an upcoming version of Prism. In the meantime, let's see how Prism handles the ubiquitous
Now, when we query
/pets, we get the following result.
Conclusion: Prism will create an out-of-the-box mock for many APIs. Although it struggled with Stripe, it works for most OpenAPI specs. It also has helpful logs.
To create a Hoverfly mock, we first have to record the calls to the API we would like to mock. I'll use my Stripe test account, where I've created three mock customers. For example, here is the information for a customer named Jane Doe.
If we call the Stripe
/v1/customers endpoint, we get information on all three mock customers.
And here's an abbreviated JSON.
Now, let's fire up Hoverfly and record our interactions with some Stripe endpoints. First, we'll need to get the Hoverfly SSL certificate so we can call the Stripe HTTPS endpoint.
We'll record several different outcomes, including failures.
Digressing for a moment, I'd like to say a word about making recordings for tests. As you saw in the example above, POST or DELETE mutates the real data backing your requests. If you're not careful, this can lead to some pretty bad consequences. That's why I would always recommend recording real server traffic.
Back to Hoverfly, let's now examine how our recordings are transformed into a mock API. We'll start by firing up a Hoverfly server.
Now, let's test retrieving a single customer.
Hoverfly produces a helpful error message indicating what went wrong. It also gives suggestions how to fix the matcher to produce a result. Here is a truncated error message:
Let's follow its suggestion and add a glob wildcard to
stripe-simulation.json. Before, the file contained this.
And now, we will change it to this.
Running our curl request again, we get the recorded response. w00t! Here's a shortened version of the response.
This is the basic flow in Hoverfly. For small APIs, I find this to be a compelling approach. For larger APIs with more complex behavior, OpenAPI-based mocks tend to perform better. This is because the spec will likely contain more outcomes and endpoints than you would see in the wild.
The first step in creating a mock with the HTTP Mocking Toolkit (HMT) is the same as the Prism mock - we download the OpenAPI spec.
We'll create a folder called
stripe-mock, where we will move the spec.
Already here, we can start HMT in server mode an examine some results.
We can see in the gist below that the result is an array of mock users built using Stripe's OpenAPI spec.
Now, let's enrich the spec with the same set of recordings we made when building our Hoverfly mock. Blending an OpenAPI spec with recorded server traffic has two main advantages:
- it allows HMT to pick up on features of the spec not present in the recordings and vice versa.
- you can alternate between serving rote recordings and synthetic data.
For example, let's record a call to
/v1/customers as we did in the previous example.
Now, let's build a spec using this mock. We'll use
gen mode. That means that if our mock runs into a customer it hasn't recorded, it will create a mock customer on the fly.
In this article, we saw how three mocking tools - Prism, Hoverfly and HMT - can create a mock of the Stripe API. I hope that, in going through this, you got a sense of the differences between the three tools. In short:
- Prism can create a mock of an OpenAPI spec
- Hoverfly can serve back recordings
- HMT can serve a mix of recordings and synthetic data