Keep container running for as long as JVM is running

[inikolaev]

I would like to use JDBC test container as a development database, but unfortunately JDBC container shuts down as soon as all connections are closed (

testcontainers-java/modules/jdbc/src/main/java/org/testcontainers/jdbc/ContainerDatabaseDriver.java

Line 203 in f436842

container.stop();

).

I would like to propose an option which could be specified in JDBC connection string to prevent container from stopping. It could be named TC_DAEMON and here's how I would like to use it:

jdbc:tc:postgresql://localhost?TC_DAEMON=true

Let me know what you think. I could work on a PR to implement it.

[zimmi]

I'm using docker compose to start up my development database and dummy smtp server. With a single command you can start it up and also blow away any data and start from scratch. That approach works quite well for me, I can share my compose file if you want. Is there a specific reason you want to add this functionality to testcontainers? I feel it's best to keep this project focused on testing only.

[inikolaev]

I like test containers approach because I can simply have a JDBC url in my configuration file and run application without thinking whether I need to run Docker Compose or not - I simply run main class from IDE and that's all.

[kiview]

I'm personally not that much convinced by this idea, since it would really push the concepts behind TestContainers. Still I understand your use case. I would as well suggest to use docker-compose instead, since having a database as a dependency is still only a single use case and most projects might need multiple external dependencies (like @zimmi mentioned with the SMTP server).

[inikolaev]

Well I think it might also be useful for tests. We recently migrated from H2 to TestContainers, but test speed degraded considerably (by a factor of 6-8) since it was starting a new container per test which in our case is not required. Instead we start Postgres container separately from tests and clean database before each test instead.

With this url parameter we could just configure JDBC connection string and call it a day, since TestContainers maintains a mapping url => container so as long as we use the same JDBC connection string across all test we would reuse existing container.

Or maybe there's a better way?

[kiview]

If you are using the TestContainers classes you should be able to use the @ClassRule annotation, so it will only started/stopped on test-class basis. If you are using the Spock version, you can use @Shared annotation. You can also build a construct where you use an abstract base class for your database tests and start the TestContainers instance manually on initialization of the class I think.

TestContainers being slower than an H2 database is in general an expected behavior, one sacrifices speed for better confidence and compatibility.

But maybe you are right and having an additional URL parameter for specifying this behavior when using the tc driver might be an useful addition, I might imagine quite a lot of people liking something like this.

We were discussing refactoring the code for extract the query parameters in #357, so it might be best to wait for this PR to be merged before starting the work in this issue.

[inikolaev]

I've been experimenting with @ClassRule but in our case we had more test cases with one or two tests, so it didn't give much win.

I have already experimented with possible fix but I'll keep an eye on the query parameters refactoring.

[asafm]

I think this idea is a good one.

…

On Tue, 6 Jun 2017 at 0:57 Igor Nikolaev ***@***.***> wrote: I've been experimenting with @ClassRule but in our case we had more test cases with one or two tests, so it didn't give much win. I have already experimented with possible fix but I'll keep an eye on the query parameters refactoring. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#359 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA8Y8RVufmmQSvPF5mBVdEpTri1mOO7Oks5sBHnhgaJpZM4NwVfh> .

[inikolaev]

While parameter parsing is not resolved I have created a PR #360 so that you could take a look at the implementation.