Closed michael-simons closed 2 years ago
How would you see this implemented, @machi1990 ?
I would have some cycles in the upcoming weeks to take care of this.
Good question @michael-simons , I do not have a recommendation or strong opinion on either really. I've seen both approaches used on the repo.
Maybe @gsmet and @geoand would know better.
Great idea!
I generally prefer the embedded way when it's an option.
Testcontainers for me is great when the service is not a JVM service.
One good reason for test containers is that selecting the version would be ideally an init parameter of the test support, pointing to the image in use. Which might even be one held in a local repo with a fixture build in. Quarkus users than wouldn't need to deal with the dependencies of the embedded Neo4j product.
I personally do recommend embedded for stored procedure development and where I am sure I have the last word about the version and dependency management. It's hard on a framework side to keep up with the dependencies it bring.
I think this can be closed since we have the dev-services support based on containers for a while now.
Description I discovered test resource and their base interface
QuarkusTestResourceLifecycleManager
. I like the fact that one can take care ofI would like to see this for Neo4j.
Implementation ideas
I have two suggestions. One based on Neo4j Testcontainers which I do maintain (see https://www.testcontainers.org/modules/databases/neo4j/) or one based on our embedded version. This could work much like the H2 resource.
I have a working implementation here: https://github.com/michael-simons/neo4j-from-the-jvm-ecosystem/blob/master/quarkus-reactive/src/test/java/org/neo4j/examples/jvm/quarkus/reactive/movies/EmbeddedNeo4jTestResource.java
I am happy to contribute this in one way or the other to Quarkus.