testcontainers
Support pausing and resuming a container
Hi!
In my integration test I like to test my apps behavior in case the database becomes unavailable. Currently I am stopping the db but of course I also want to test the recover of the database with its former state. Even if don't mind loosing the former db state I still have to create a new db pool because port changes on every container spawn and the already injected one can never recover.
Two options come to my mind to solve the issue:
- Allow defining an explicit mapped host port
- Allow to pause and continue container without changing the mapped host port (my preferred option)
Thanks
Are you (probably) looking for adding docker's pause/unpause to testcontainers api?
I have never heard of docker pause but it seems like a reasonable thing to implement so I am gonna accept a PR that adds a pause and unpause API to Container and ContainerAsync.
Stupid question: wouldn't it make more sense to just use stop and start instead of introducing a new pause/unpause, to have it more "in line" with the Java implementation like documented on the website https://www.testcontainers.org/test_framework_integration/manual_lifecycle_control/?
I think it feels "more natural" when having both ecosystems (Rust + Java) using the same method language.
Hi @FibreFoX, I'll try to answer
stop + start recreates container (with graceful shutdown logic by sigterm signal or sigkill in case of hanging), so the state of such container will be dropped. For in-memory databases it's critical.
While pause/unpause doesn't.
One more case is introducing some controlled delays.
Just a different behavior and could be useful for testing purposes.
Anyway, it's official docker API for suspending processes. And I don't think we should avoid this for aligning APIs.
@DDtKey Thanks for clarification, I wasn't aware that stop + start actually recreate the containers instead just stopping and re-starting the container. And sure, this is a very special scenario.
If I understand correct, the testcontainers-java should have an open issue to feature-request this too, right?
One more case is introducing some controlled delays.
You could also use toxiproxy for this. I used this in some JVM project a while ago for testing (I used the java module there) and IMO it was pretty neat.
