While there are some threads here and there on the forum discussing some points about api mock tools, I haven’t been able to understand why or how people choose one tool over the other.
Hence, I created this thread in an attempt to gather and combine everyones thoughts and experiences with the various tools in the market, while also asking to share their use cases and how were they able to utilise the specific tool under question.
To add a bit of context - I am preparing a POC presentation about mock tools in our company to possibly identify whether or not we should switch to a new mocking tool or stay with the one currently in use (WireMock).
Based on my research, quantifying the general interest of QA folk and testers it came down to several tools that are most widely used in the market:
WireMock
Postman Mock Server
Beeceptor
Mountebank
MockServer
and the rest.
When thinking about comparing mocking tools in a company scope, I also tried to come up with the some criteria by which one could compare one tool to the other:
Ease of use / setup process
Range of capabilities and how complex can it be to utilise most of what the tool can offer
Pricing (I would assume that most on the list are open source. However, tools as postman do require you to purchase a package to use some of the advanced features - postman mock server in our case - which can get quite pricey!)
Security (This, on part, depends on how/where the tool runs. In most cases, the tools can be server-hosted locally, eliminating the risk of information leakage as the sensitive data is cycling only within the company. However, if we look at Beeceptor, which is cloud-based on the vendor side, we do encounter some risks related to PII and other sensitive info going out of the company’s circle, which could pose certain security risks)
These are the criteria that I came up with when thinking about factors that could impact stakeholders decision on which tool to use. Feel free to add anything that could’ve gone under my radar.
Also, I would be glad if you guys shared your experience with the listed tools!
Which one have you been using?
Why do you keep using it?
What are your use cases for mocking?
Add anything else to the discussion you think would be beneficial!
MITMProxy. My goal was to find something flexible which didnt make technology assumptions about the rest of the stack (like wiremock does).
One use case Im particularly interested in is recording/playback with variations. I find that it’s quite a common use case for an API call request and response to be extremely fat and there will be a few things in there which will make the request/response cycle nondeterministic, like, for instance:
The requestor creating a GUID (different each time). This makes matching the recorded response which matches that request tricky.
Different ordering of things buried in a list somewhere.
Timestamp being sent as a key and the response coming back somewhere.
Timestamp being part of the authentication mechanism.
I tend to find I need a bit of code to accommodate these things. The goal for me is that the server is flexible enough to handle these things without requiring oodles of code and being able to handle recording APIs in a real mode.
After trying most others from your list, my personal go to is - Beececptor
My reasons:
Beeceptor, despite being a cloud-based service, has been the simplest solution I’ve come across. It required me virtually no setup time and, as a hosted service, it doesn’t need any additional dependencies or libraries.
Although I enjoy coding, still to empower my entire team, I found it super quick to adapt
as it’s a no-code solution, offering recording and mock responses, which simplifies testing and saves me also time which otherwise needed on maintenance of the scripts.
Found it a distinctive combination of mocks, proxy, and rules allows for easy customisation of HTTP requests.
Soon we had security and auditing urgency, and it being certified with SOC 2 Type II and ISO, indicating a strong commitment to data security, made us continue using.
They also maintain a public uptime status page for transparency.
I had no knowledge about ISO certification the Beeceptor had acquired about data security.
However, even with the certification, in my case, we were not able to push through with Beeceptor.
The reason was that the country in which we’re launching the product has extremely strict data management policies, which basically prohibits any and all streams that could flow outside the company to third parties.
We decided to move on with WireMock since it enables local hosting, ensuring the information is cycling through within our walls.
I currently use WireMock. It’s been pretty great being able to auto build out mock apis and get them set up. We’ve found it pretty easy to utilize and build out. We also picked it due to being able to set up Pacts with PactFlow which we are currently POCing right now as an add on to our integration test suite.
I’ve used mockpi.co a lot and it’s really great. Much better than Wiremock & Postman if you have complex mock requirements. It gives you infinite flexibility to create API mocks with a lot of behaviours like random or condition based http codes, pattern matching, dynamic configurable response data, latency etc.
Great topic to bring up—it’s definitely something many QA teams and developers grapple with, especially when scaling or refining processes. Mocking APIs effectively can make or break the efficiency of testing, so choosing the right tool is crucial.
Here’s my two cents on this:
Tools I’ve Used and Why:
WireMock:
This has been my go-to in several projects. Its ability to run locally, simulate realistic delays, and handle complex stubbing scenarios makes it a solid choice. The learning curve might be slightly steep for beginners, but once you’re comfortable, it’s incredibly powerful for extensive API testing.
Postman Mock Server:
While Postman shines in API exploration, its mock server feature works great for lightweight use cases. However, the pricing for advanced features can be a dealbreaker, especially if you’re working in a budget-conscious environment.
Mountebank:
I love its versatility—it supports more than HTTP (like TCP), which is rare for mock servers. The JSON-based configurations are a bit unconventional, but it’s worth exploring if your use cases extend beyond basic API mocking.
Beeceptor:
Fantastic for quick mocks without setup, but as you mentioned, the cloud-based nature can be a concern for data-sensitive environments. I usually recommend it for personal or non-critical use cases.
MockServer:
This one’s a recent discovery, and I’m impressed by its Java-first design. It integrates well into CI pipelines but requires more technical expertise, so it might not be ideal for teams with mixed skill levels.
Factors I Think Matter Most:
The criteria you outlined are spot on. I’d suggest adding a couple more:
Integration with CI/CD Pipelines:
Some tools play nicer with automation and pipelines than others. For example, WireMock’s standalone server can seamlessly fit into Jenkins or GitLab workflows.
Community and Support:
A thriving community can be a lifesaver. It’s worth considering tools that are well-documented and actively supported—Postman and WireMock have an edge here.
Performance Under Load:
Mock servers can sometimes buckle under high parallel requests. Testing this upfront, especially for tools like Beeceptor or Postman Mock Server, is critical.
Use Cases and Recommendations:
For rapid prototyping or demonstrating an API workflow in meetings, I lean on Postman or Beeceptor—they’re simple and fast.
For end-to-end testing in a secure environment, WireMock or MockServer shine because they’re local and robust.
If I’m testing systems with protocols beyond HTTP, Mountebank wins every time.
To wrap it up, I’d say the decision comes down to your team’s expertise, the complexity of your use cases, and budget constraints. If WireMock currently works for you but lacks a specific feature, it might be more cost-effective to extend its functionality (e.g., custom scripts) than switch tools entirely.
Looking forward to hearing what others think. Always great to see how different teams approach API mocking!