Repository navigation
Using multiple JVM instances through forking prevents singleton containers from working as intended #2939
Description
When using maven-surefire-plugin or maven-failsafe-plugin with activated forking (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#forkCount + https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#reuseForks) a new JVM might be spawned for every test. This will prevent the pattern from working as intended as every JVM instance does its own classloading and thus "reloads" the abstract class containing the static container instance.
The only solution is not to fork at all or to only fork once and resuse the JVM for all tests (forkCount=1 + reuseForks=true).
If forking is mandatory for any reason (e.g. isolating testcases) there currently seems no way to use the pattern described here
https://www.testcontainers.org/test_framework_integration/manual_lifecycle_control/#singleton-containers
As it took me quite some time to find the underlying issue a small hint concerning forking during tests in the description of the pattern might save others some headache.
Having a standard mechanism of declaring singleton containers that even work with forking/multiple JVMs of course would be even better - a possible approach was discussed here: #1441
I assume there might be the need for a central entity (container?) orchestrating the communication/access of all the tests to the containers that are decoupled from the lifetime of the instantiating JVM, as well as the lifecycle of those containers.
One could of course argue that using containers like this in the context of tests is an anti-pattern.
But depending on the requirements (e.g. performance) or the effort to restructure the test-suite to allow for small, fast, atomar containers singleton containers might be the only viable approach, or at least a starting point for a better solution.
Activity
bsideup commentedon Jun 25, 2020
Not being able to reuse singletons between multiple JVM's is kinda obvious and applies to any static constant on JVM, not just the singleton containers.
If you need to reuse containers between JVMs (and their runs), you can try #1781. Other than that, there is nothing we can do to help here, really. There is no magic behind the "singleton containers", you just define it once as a static variable (hence "singleton") and start, so it is basically a JVM's feature, not Testcontainers'.
bseiller commentedon Jun 28, 2020
Haha, yes that it absolutely true, actually I was debating with myself if I should add the word "obvious" to my already convoluted description. But as it had taken me quite some time to understand that the maven plugin was configured to do forking (by default there is no hint to that during the build process) the problem as a whole just didn't feel obvious any more.
A small hint along the lines of the following
Be aware that if you have activated forking in the configuration of your test plugins this approach will not work for obvious reasons.at the end of the text herehttps://www.testcontainers.org/test_framework_integration/manual_lifecycle_control/#singleton-containers
would have helped me realizing much faster what I was missing and where to look for problems.
Thank you very much for pointing #1781 out to me - I'll have a look if I can get to work that way.
Fix failed tests for branch-2.10 (#15995)
Fix failed tests for branch-2.10 (apache#15995)