Unit tests and functional tests focus on testing your service code without calling other network resources, whether they are other microservices from your application or third-party services like databases, queues, and so on. For the sake of speed, isolation, and simplicity, network calls are mocked.

Integration tests are functional tests without any mocking, and should be able to run on a real deployment of your application. For example, if your service interacts with Redis and RabbitMQ, they will be called by your service as normal when the integration tests are run.

The benefit is to avoid falling into the problems that were described earlier when mocking network interactions. You will be sure that your application works in a production execution context only if you try it for real.

The caveat is that running tests against an actual deployment makes it harder to set up tests data, or to clean up whatever data was produced from within the service during the test. Patching the application behavior to reproduce a problem is also a difficult task.

But along with unit and functional tests, integration tests are an excellent complement to verify your application behavior.

Typically, integration tests are executed on a development or staging deployment of your service, but if it's easy to do, you can also have a dedicated testing deployment, which will be used for that sole purpose.

You can use whatever tool you want to write your integration test. A curl script, for instance, might sometimes be enough on some microservices.

But it's nicer if integration tests can be written in Python, and can be part of your project's tests collection. To do this, a Python script that uses requests to call your microservice can do the trick. Or better, in case you provide a client library for your microservice, it's a good way to test it.