[
https://issues.apache.org/jira/browse/SOLR-17653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17924309#comment-17924309
]
Jan Høydahl commented on SOLR-17653:
------------------------------------
I have some experience with JUnit and testContainers. In general, works like
magic, but there are a few tings to watch out for
* You can start a container from a Dockerfile, but it of course takes ages to
run the test due to the image building, pulling stuff from hub
* When addressing the new container from a test, it may work with "localhost"
when run locally, but once in CI/CD it may be something else
* Solr code running in the container cannot use localhost to address another
node in another container. Must either use docker networking (preferred) or
"host.docker.internal".
* Cleaning up (docker prune system or similar) as part of test harness may
avoid buildup and disks filling up with old images or volumes.
> New DockerSolrServerTestRule that uses TestContainers/Docker
> ------------------------------------------------------------
>
> Key: SOLR-17653
> URL: https://issues.apache.org/jira/browse/SOLR-17653
> Project: Solr
> Issue Type: Test
> Components: SolrJ, test-framework
> Reporter: David Smiley
> Priority: Major
>
> We've got a {{SolrClientTestRule}} abstraction in our test infrastructure
> that makes it easy for a test to work with Solr in an abstracted sense, using
> a SolrClient to talk to it. This issue proposes a new implementation that
> uses an Http SolrClient (of configurable implementation) to talk to SolrCloud
> (embedded ZK) running on a single node in a Docker container, and using
> TestContainers to facilitate the integration. Future extensibility: the
> implementation could consider multiple nodes thus multiple containers. The
> location of this utility could be a new artifact (JAR) living in the docker
> module with appropriate dependencies, or just put in solr-test-framework.
> This would be extremely useful! We could then write a hello-world SolrJ
> SolrCloud test in which Solr is running semi-realistically. This is all we
> need for easily adding some backwards-compatibility tests, in either
> direction (SolrJ 9 to Solr 10, and SolrJ 10 to Solr 9). Both directions are
> useful in a rolling upgrade. Tests using this in our test suite should be
> demarcated / separated somehow so that running such tests is opt-in, not part
> of the "check" task.
> The addition of this may draw into question the validity/utility of our
> Docker bats tests, that could perhaps instead be using this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
