I am currently building an application that consists of multiple small rest services that communicate between them. For example, a request to service A might make requests to services B and C in the background.
The question is, how can I mock the services B and C in order to test A (that includes checking if the requests to B and C are correct)?
The services themselves are written in python using Flask and golang.
You could generate the code for all services out of a formal definition. Then you could start coding and replacing each service individualy and work against the existing mock (generated form your definition).
Have a look at raml (http://raml.org/) or swagger (http://swagger.io/) which both take a formal definition of your service/api (e.g as json or yaml) and provide tools to let you generate the boilerplate code. .
There probably are other tools to mock apis but these are the ones i had in my head now. You can even generate a nice documentation for your api.
Mountebank (http://www.mbtest.org) is an excellent test double application for exactly this sort of purpose. The application creates a HTTP listener on a port, on which you can create canned responses to a number of request routes that your real API would serve. You can create an imposter that behaves as the real service would, except it will always return your fake test data, and then configure your application under test to direct its requests to Mountebank rather than the real thing.
Each route in the system keeps a log of all requests received, and you can then interrogate these using a REST API to determine that the correct requests are being sent by your application under test. It is also possible to configure each faked endpoint to return different results, conditional on the request received - so you could have it return an error response when a certain query string parameter is not set, for instance.
It's quite powerful and flexible, but will take you a little while to set up as you need it. In addition, you will need a machine with a NodeJs installation to run it in.
There are a variety of services to design, test and document RESTful APIs, here are two that I can think of off the top of my head.
Postman can be used to test RESTful services and create collections of tests.
Postman has a variety of features which are useful for single developers as well as teams.
The use Postman with GitHub and a CI service to ensure all new releases continue to work as expected can arguable be considered essential to the longevity of your applications health.
Apiary is a large, well rounded API management platform, however, the plans are more focused on Open Source projects and Enterprise customers.
Apiary allows for automated testing of unlimited public API's and has powerful automatic testing builtin.
I would suggest you split this out into two tracks, unit testing and end-to-end (integration testing. It depends on what your goal is here.
The question is, how can I mock the services B and C in order to test A (that includes checking if the requests to B and C are correct)?
It makes little sense to want to use a real URL in order to receive a fake response.
If the goal is to assert that the content of the requests is correct, then you can observe this by having your local service use a mocked http client, one which does not actually make a call to the external service, but merely records how it's being used (and potentially returns a mocked result).
If the goal is to assert that the web request itself is correct, in terms of having the correct URL and formatting the request correctly; that is something I would figure out using end-to-end tests with real services and specific scenarios that highlight the high level behavior I'm expecting from my application/ecosystem.
Keep in mind that at this stage, your unit tests will have already weeded out any issues with the content of the request, so now you can focus solely on the structure of the request.
If your response to this is "but I call the URL directly, I don't wrap my logic in an abstracted HTTP client", the short answer is that this use case is one of the major reasons why you want to abstract your IO access, so that it can be mocked when running tests.
