I was interested in hearing people's experiences of using mocking, specifically for API testing.

Whilst I’m (fairly!) well versed in automation techniques now, I haven’t yet used this approach but would like to find out more about it. I’m just interested to hear people's opinions on the tools which are good to get to grips with(regardless of language), tutorials, etc. Wiremock is one I have seen referenced quite a bit but was interested to hear about others too.

I know that I need to firm up my understanding in this area as I’m yet to fully understand why as a tester we’d want to mock APIs(I’m sure in time, all will be revealed!)

  • 1
    That depends on which API you mean?
    – Alexey R.
    Commented Jul 27, 2018 at 11:02
  • 1
    Sorry Alexey, I was meaning Restful APIs Commented Jul 27, 2018 at 13:52

6 Answers 6


Depends on what your resources are you might want to use either online service like

or you might install

  • either SoapUI
  • or Postman
  • or Wiremock that you have already mentioned.

When you use online services you are usually limited with your pricing plan. Standalone solutions allow you to be more flexible but they are usually a bit harder to maintain.


Beeceptor.com, is very powerful tool and i believe it should suffice your need. You can easily do below:

  1. Mock your responses
  2. Introduce delay
  3. Or even just use this as proxy to route your requests to your server.

In my case, my server uses third party tool to fetch responses so I have made changes to my config file to hit the beeceptor.com and then through beeceptor I hit the third party tool. While doing this I did mocking of responses as well as delaying the responses.

With the same approach you can send error codes and error messages to your system and see how it accepts. This way you can touch the places where you can't test in real life scenario.

If in your case, you want specific response after hitting the api, try to configure that API as end point in beeceptor and then you can hit beeceptor end point.

Hope this helps!!


Mocking some endpoint is a must when your application connect to other host which you can't manage all the time , (Eg. third party api to send sms or email)

Because sometimes the endpoint do a weekly maintenance or make a change without you knowing it.

Also as a QA you want to do a negative case and you want the endpoint give you specific result that hardly to produce because of the server side not under your control

Iam still trying castle mock to fit in my needs , maybe you can give it a try too.


Currently we are using QuickMocker (https://quickmocker.com). This is on one hand pretty simple online api mocking tool with a very intuitive UI, but on another hand it allows to perform things which other online tools do not have:

  1. Regular Expressions in the URL allowing you to create an endpoint which will cover any resource. For instance I do not need to create a separate mocks for 'GET /user/1' and 'GET /user/2'. Instead I can simply create 1 mock with the URL 'GET /user/([0-9]+)' . Just do not forget to enable the RegExp feature for the endpoint!
  2. Easily change the order of the mocks. For instance if you want still GET /user/3 to return different response or HTTP status code (e.g. 404 Not Found), you can put this mock on top of the previous with a drag and drop and it will take advantage over the user RegExp mock we've added earlier. In case you do not need it anymore, simply move it below or disable it (or finally remove it).
  3. It support shortcodes, so you can make your response to look more dynamic. The best thing that it has a shortcode for the parameters we caught with the RegExp.
  4. An excellent tool to capture and view all the requests that were done to your mocks.

Finally this thing become a "must have" when you develop some integration with 3-rd parties which support webhooks. Online api mocking tool like Quickmocker (https://quickmocker.com) are very helpful in such cases, because it provides you with a real URL that is available on the Internet and you can see immediately all the request information (header/body) you receive from the 3-rd party.


API mocking tools are extremely useful for building API clients while the backend is being implemented. An API client is anything that consumes an API, so it includes UIs, CLIs, and other backend services. Using API mocks also forces you to think harder about the design of your API and to document it, both of which are good practices.

In the absence of API mocks, many teams use JSON examples as "documentation". This is a flawed approach, since JSON examples are not descriptions/schemas of the payloads and therefore have tons of limitations. For example, JSON examples can't tell you which fields are optional (unless you have a large collection of examples).

In my own experience, API mocks have been a life-saver in many situations, as they allow you to work on the client without relying on the backend as the source of truth. When it comes to APIs, the source of truth should be the documentation/specification.

In the past few years, there has been an explosion of services and libraries offering API mocks. I can recommend the following:

Of course, using mocks is not a replacement for testing the integration between the client and the actual server, but if you can make sure that client works with a server mock based on the API specification, and at the same time you validate that the server complies with the specification (using for example schemathesis ), you'll be in a good position to deliver a successful API integration.


I would suggest to use spring boot application to mock all your end points. Spring boot application can be deployed using tomcat or it can run as stand alone jar application. You can generate any possible scenarios for positive and negative testing. We are using this in our project and it's provide lots of flexibility also.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.