[
https://issues.apache.org/jira/browse/SOLR-18150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-18150:
----------------------------------
Labels: pull-request-available (was: )
> Introduce SolrBackend abstraction for tests & benchmarks
> --------------------------------------------------------
>
> Key: SOLR-18150
> URL: https://issues.apache.org/jira/browse/SOLR-18150
> Project: Solr
> Issue Type: Test
> Components: test-framework
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I propose a basic abstraction for tests & benchmarks to interface with some
> kind of running Solr: EmbeddedSolrServer, JettySolrRunner,
> MiniSolrCloudCluster, a remote (SolrJ Http) Solr, and perhaps a variant of
> that coupled to a Docker container. Unlike SolrClientTestRule, it shouldn't
> be tied to JUnit. Having seen many tests, and solr/benchmark, the principle
> things needed are:
> * create a "collection" (or "core" if not in SolrCloud, but using the same
> API). Must specify the configSet and a map of any name-value properties that
> will be used for substitution when reading the configs. The neutrality on
> collection vs core is a key aspect of the whole abstraction.
> * indicate if a collection exists already -- esp. for benchmarks to reuse a
> collection
> * create/upload a configSet given a path to one. Obviously done before
> creating a collection. Reminder: configSets can be used in both Solr modes
> * indicate if a configSet exists already -- esp. for benchmarks to reuse a
> configSet
> * reload a collection
> * provide a SolrClient for doing the work of the benchmark/test scoped to a
> collection. Needs a means of customization (e.g. http1)
> * provide a SolrClient for doing administrative tasks -- tasks *not* in scope
> of the benchmark/test but nonetheless needed to set things up
> * and more can be added of course
> The SolrBenchmark wouldn't generally be used directly by a benchmark/test,
> but it'd be one layer away. Thus I propose SolrClientTestRule delegate/use a
> SolrBenchmark, and similarly SolrBenchState would likewise. Both those
> things can tend to some unique benchmark/test matters. By being a new
> abstraction that isn't tied to JUnit, it should be easy to add support for
> new/different test frameworks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
