Coverage Report

I'm not fully happy with this
@brenoepics if you have interest in enhancing the local test experience with testcontainers, you might take some parts of this PR into a new PR

Yeah I feel the same about #1424, probably gonna make a new PR with something better. I took a look at this one and right now it creates a new container for every single test case. Feels like overkill, right? Can’t we make something that just spins up one container, takes a DB snapshot in a beforeAll, and then restores it in an afterEach?

This original PR stats were:

Duration 120.03s (transform 1.17s, setup 0ms, collect 5.93s, tests 120.02s, environment 15ms, prepare 5.33s)

After the container changes:

Duration 30.49s (transform 1.18s, setup 0ms, collect 6.20s, tests 30.45s, environment 17ms, prepare 5.54s)

So yeah, way faster, but I still wanna dig deeper since I’m more used to Java testing and mocking.

The thing is even with this improvement we’re still spawning child processes for each test which definitely adds some overhead. Plus every time we spawn the container stuff adds to that too. There are some writeFile calls but those should be negligible.

Also because of the way we do things with child processes we can’t really mock files properly which is another reason I was thinking of moving the code out of the bin and dropping the whole child process spawning thing.

The biggest "problem" is that the integration tests are especially running for each supported postgres version in parallel

for local container testing I think only the latest postgres is important, but then we would need to define a flag or mode to optionally run other versions and in GitHub actions the full suite runs again in parallel