Fix structure of testcontainer integration tests #1135

New issue

Open

opened 2026-05-25 10:50:15 +00:00 by a24hirsa · 0 comments

a24hirsa commented

2026-05-25 10:50:15 +00:00

Collaborator

Additionally some services will need to build the same containers, mainly the postgres and middleware. The middleware has the longest build time and every real database test will need to have a postgres container so making some way to only need to build these once for a full testing set for different services would be wise.

We currently utilize Testcontainers network creation capabilities to allow communication between containers on that network. Testcontainer also has documentation about allowing container to swap networks. This could possibly be used to allow tests to use the middleware in different orders

https://dotnet.testcontainers.org/api/create_docker_network/

This could be worth looking into to make the heavyweight middleware and the postgres to only need to be built once when running tests for multiple services before deployment or builds and regression tests in the future.

This could be seperated into multiple different issues,
-Create singel creation middleware and postgres
-regression testing
-full suit test before builds script(most likely once every service atleast has some integration tests up and running)
-Seperate out test container and test classes

Currently integration test are written in a single test file with two separate classes one for creating the contianers and webhost and the other for making tests. These should be separated into two separate files if possible. Additionally some services will need to build the same containers, mainly the postgres and middleware. The middleware has the longest build time and every real database test will need to have a postgres container so making some way to only need to build these once for a full testing set for different services would be wise. We currently utilize Testcontainers network creation capabilities to allow communication between containers on that network. Testcontainer also has documentation about allowing container to swap networks. This could possibly be used to allow tests to use the middleware in different orders https://dotnet.testcontainers.org/api/create_docker_network/ This could be worth looking into to make the heavyweight middleware and the postgres to only need to be built once when running tests for multiple services before deployment or builds and regression tests in the future. This could be seperated into multiple different issues, -Create singel creation middleware and postgres -regression testing -full suit test before builds script(most likely once every service atleast has some integration tests up and running) -Seperate out test container and test classes