Docker compose taking up a lot of resources #272
-
Hello @cristianrgreco , first off great library! I had a question about the general architecture of integration testing with this library. I have Jest test suites that spin up a new compose environment per suite. I did this to have isolation between the suites. This seemed to be fine initially when I only had a couple suites, but as more are being added it's not scaling and the tests are crashing on local machines because of resource limitations. I was wondering how this library is generally intended to be used in regards to integration testing. Is creating a new compose environment per suite overkill? Are the tests meant to be run in band with the environment stopping between suites? Is the compose environment meant to be shared across tests even though it may cause issues with isolation? Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Hi @breauxna, thanks for the feedback! In an ideal world you could spin up a single docker-compose environment for your entire test suite. Whether that's feasible depends on your use case, for example is the service stateful? Can the state be cleared between tests? Do the boundaries make sense? Etc. Obviously running enough docker containers or any intensive task in parallel will eventually exhaust system resource. If it cannot be optimised then I'd suggest running the test suites in band as you suggest. That way at least resource is less of an issue, and you could for example split the suites across multiple machines to once again run them in parallel. I would say though that this is less a concern of testcontainers and instead a more general problem of how to manage a growing and resource intensive test suite. Let me know if I can help with anything else. Cheers |
Beta Was this translation helpful? Give feedback.
Hi @breauxna, thanks for the feedback!
In an ideal world you could spin up a single docker-compose environment for your entire test suite. Whether that's feasible depends on your use case, for example is the service stateful? Can the state be cleared between tests? Do the boundaries make sense? Etc.
Obviously running enough docker containers or any intensive task in parallel will eventually exhaust system resource. If it cannot be optimised then I'd suggest running the test suites in band as you suggest. That way at least resource is less of an issue, and you could for example split the suites across multiple machines to once again run them in parallel.
I would say though that this is les…