Investigate local development with devtools and testcontainers
See https://bsideup.github.io/posts/local_development_with_testcontainers/. We might be able to automate some of this if devtools is being used.
Here's one possible idea from @bsideup https://gist.github.com/bsideup/5077bb332e38814abe27905e28e62fc3
Also https://github.com/joshlong/testcontainers-auto-services-prototype
I would love to use testcontainer to manage my containers at runtime localy, not only in tests
In case anyone wants to use such feature today, it is a part of Just: https://just.maciejwalkowiak.com/docs/usage/just-run/
After some discussion with @eddumelendez and @bsideup today at Devnexus one option that came up was the idea of launching a version of your application from src/test/java so that it can easily access test dependencies and test code.
This is quite appealing because it solves the issue of where/how do you configure test containers when you want to use it a development time.
The basic idea is that you'd create a new class with a main method somewhere under src/test/java that you could launch when you want to run your application with test containers. For example, say you have MyApplication.java under src/main/java. You'd create an equivalent test version call TestMyApplication under src/test/java. When this version runs it has access to the entire test classpath and all test code.
The TestMyApplication class would need to launch the real class and be able to add additional @Configuration classes. We might be able to use SpringApplicationHook to do this, perhaps with some additional helper classes to make it very easy. One idea is:
@Configuration
public class TestMyApplication {
// extra config
public static void main(String[] args) {
SpringApplication.from(MyApplication::main)
.with(TestMyApplication.class)
.run(args);
}
}
We could allow test container instances to be registered as beans which we could then pickup and convert to service ConnectionDetail beans so that auto-configuration works.
Another thought, this would allow the fairly common pattern of a custom container subclass to work with a simple @Import.
I've opened the following issues to provide support for testcontainers at development time:
- [ ] #35019
- [ ] #35021
- [ ] #35022