How can integration tests for micro services be written?

Question

Writing unit and integration tests for individual micro services is part of standard development processes. However, how can these services be tested with one another? And then integrated into a CI system? As well as respecting the correct ports, shared network and secrets. Should the individual micro services be versioned in the same Git repo? For context, I use docker compose with a Flask app that acts as the oauth2 server for a Grafana instance. Other instances include PostgreSQL, Redis, nginx and InfluxDB.

A simple approach would be to test the individual APIs, but what if they change on one side but not updated on the other? How can it be made sure that the APIs are being used correctly in the first place?

Answer 1

Well, the name "integration" test means to test different pieces of the system together, I would not call a test that only uses one component an "integration" test.

You'd wire them up like in production (in a testing environment, of course), provide test data and let them do their thing. The components themselves do not need to know - they should not know - that they are under test.

The "wiring up" should be as similar to the production environment as possible, re-using configuration code where possible, to test those bits&pieces as well. Don't put them in the same repo just because you do integration tests.

To see whether the components work together correctly, you would have a test driver that exercises several of them together. It will set up the test data and look at the end results. If everything is green, then the APIs have, by definition, been used correctly. This means that there should be plenty of integration tests - if in doubt, I'd err on the side of having too many integration tests rather than too many unit tests. Obviously this depends a lot on what you are actually doing...