rmandlx
commented
3 years ago Im still not sure how to implement Integration testing for the Backend. So far i have tried using the Testcontainers library, that can be used to start up docker containers using java code. Basically i got it working up to the part, where i could start the database containers correctly and configure the current service under test to use the correct database connection string (this is not as straight forward as it seems, because Testcontainers starts the containers with random ports, so you can't statically configure the port in the application.properties. I had to change the database connection string at runtime, see: https://github.com/amosproj/amos-ss2021-bike-nest/commit/5fc460dd0676d54fb9b44cc8a86f9adc666adb25#diff-f3e0d2594b81305b77b8c4f5e215f857c71f9b60a3eecf6a1cbda1697f7d71ebR36)
This is also the reason, why i thing it might not really be possible to start all containers with docker compose. if the user-db is exposed on port 40424 then how do we tell this the usermgmt service? Im still doing some testing to check if there are ways to get it to work but I also thought about some alternatives already.
Our problem is basically, that each microservice could possibly communicate with another microservice, so for an integration test we not only need to have the database for each microservice running, but also all other microservices have to run. So the solution would be to just setup everything in a way, that all services expose their ports to localhost, but there are no port conflicts. something like: user-db listens on 3306, booking-db listens on 3307, user-service connects to 3306 and exposes port 9001, booking service connects to 3307 and exposes port 9002
then we can configure the feignclients in the test application.properties and all services should be able to run. for our integration test we could shutdown the service under test and replace it with the test runner... or should we just create the service under test with a different port? that way circular feign calls will not work (lets say we start user-service with port 9001 and for testing we start the user service instance again at 9008. from the user service testing instance we might do a few feign client calls to other services. if as a result of one of these calls, another service calls the user-service, it will probably call the user-service with port 9001. i don't think we will run into such a case at all, but we should keep it in mind
For Integration Tests, we need to create another CI Pipeline, that can start up other services via docker. Because as I understand it, Integration Tests check, if the services can correctly communicate with one and another.