javabotdreamreal's title: "Testcontainers and Reuse | Hacker News"
dreamreal(I did not post this to HN)
Paradreamreal: neat, i'm gonna steal that
dreamrealPara: :)
dreamrealIt's definitely nicer - my builds for nevet lost five literal minutes on deployments
deeboi've been kinda battling the opposite of that in spring boot, if you use jdbc:tc:postgresql as the spring boot jdbc url, context caching still reuses the same underlying container for new contexts
deeboso all tests have to make sure they can run with possibly garbage data left by other tests not running transactionally (intentional or not)
dreamrealHmm, I wonder how that's propagating: on my machine, every module was getting its own container and choking docker out
dreamrealmoving to unique scoped *databases* cleared everything up
deeboat this point i've forgotten what the issue was, each new context in the cache had its own hikaripool to the same db, but somehow new containers were not started
dreamrealThat's the problem *I* had! New containers were taking too long to initialize
dreamrealso now: one container, so it initializes ONCE, and new dbs can be created and destroyed instantly because connecting to postgres doesn't have to wait on docker
deebomaybe the container is created on Class.forName() or something so it's only done once per jvm, never looked into how jdbc testcontainers work
ParaFeel free to steal if there's anything worth stealing.
dreamrealdeebo: if you don't explicitly turn on reuse, it starts a container for every JVM
dreamrealbut turning on reuse isn't enough, you also need to differentiate schemas if they differ
deeboyeah we don't fork tests from gradle and any multimodules are trivial, mostly for sharing domain classes etc so basically single jvm for tests
dreamreal*nod*
deeboyeah the driver has one container per url, i remember testing adding like ?cachebust=${time} or something and it made it work, but broke something else