[
https://issues.apache.org/jira/browse/SOLR-11872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17305555#comment-17305555
]
David Smiley commented on SOLR-11872:
-------------------------------------
_I'm hoping to get the interest of a GSoC student..._
h1. GSoC 2021 Readme
Apache Solr is a popular search engine, and is an old and successful project.
The foundation of the test infrastructure was written in a way that we'd rather
not keep, with the benefit of years of hindsight. In particular, it was written
before there was a SolrClient abstraction. The project has a plan to revamp the
tests to use the SolrClient abstraction and thus make the test code look more
like real Solr client-side code, and also enable tests to run in a variety of
modes (standalone Solr, SolrCloud, Docker-ized Solr). Some design and judgement
will be needed to explore some of the particulars that are TBD, and then a lot
of work to update many of the tests. There are some follow-on / stretch goals:
One is ensuring that there's a Docker based test mode that can run from the
Gradle build and that which would run in CI. Another is exploring how tests
might easily define configuration aspects in the code instead of polluting more
and more test configuration files that are difficult to maintain. This
revolution in test infrastructure is highly appreciated work by not just Solr
developers but anyone who writes Solr plugins that use the framework!
Difficulty: Medium
– The most difficult aspect is in digesting a large codebase, even if mostly
limited to the test aspect. The actual work/code is probably not difficult.
There will be many tests to potentially update.
Language: Java
Mentor: David Smiley
> Refactor test infra to work with a managed SolrClient; ditch TestHarness
> ------------------------------------------------------------------------
>
> Key: SOLR-11872
> URL: https://issues.apache.org/jira/browse/SOLR-11872
> Project: Solr
> Issue Type: Improvement
> Components: Tests
> Reporter: David Smiley
> Priority: Major
> Labels: gsoc2021, mentor
>
> This is a proposal to substantially refactor SolrTestCaseJ4 and some of its
> intermediate subclasses in the hierarchy. _In essence, I envision that tests
> should work with a SolrClient typed "solrClient" field managed by the test
> infrastructure._ With only a few lines of code, a test should be able to pick
> between an instance based on EmbeddedSolrServer (lighter tests),
> HttpSolrClient (tests HTTP/Jetty behavior directly or indirectly), SolrCloud,
> and perhaps a special one for our distributed search tests. STCJ4 would
> refactor its methods to use the solrClient field _instead of TestHarness_.
> TestHarness would disappear as-such; bits of its existing code would migrate
> elsewhere, such as to manage an EmbeddedSolrServer for testing.
> I think we can do a transition like this in stages and furthermore minimally
> affecting most tests by adding some deprecated shims. Perhaps STCJ4 should
> _become_ the deprecated shim so that users can still use it during 7.x and to
> help us with the transition internally too. More specifically, we'd add a new
> superclass to STCJ4 that is the future – "SolrTestCase".
> Additionally, there are a bunch of methods on SolrTestCaseJ4 that I question
> the design of, especially ones that return XML strings like {{delI}}
> (generates a delete-by-id XML string) and {{adoc}}. Perhaps that used to be a
> fine idea before there was a convenient SolrClient API but we've got one now
> and a test shouldn't be building XML unless it's trying to test exactly that.
> For consulting work I once developed a JUnit4 {{TestRule}} managing a
> SolrClient that is declared in a test with an annotation of {{@ClassRule}}. I
> had a variation for SolrCloud and EmbeddedSolrServer that was easy for a test
> to choose. Since TestRule is an interface, I was able to make a special
> delegating SolrClient subclass that implements TestRule. This isn't essential
> but makes use of it easier since otherwise you'd be forced to call something
> like getSolrClient(). We could go the TestRule route here, which I prefer
> (with or without having it subclass SolrClient), or we could alternatively do
> TestCase subclassing to manage the lifecycle.
> Initially I'm just looking for agreement and refinement of the approach.
> After that, sub-tasks ought to be added. I won't have time to work on this
> for some time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
