[
https://issues.apache.org/jira/browse/SOLR-11872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16971913#comment-16971913
]
David Smiley commented on SOLR-11872:
-------------------------------------
I think there are basically two tasks:
(A) SolrProvider test utility. It provides SolrClient instances, and will take
care to close them when tests end. The biggest part of this is that it
provides mechanisms to choose what sort of backing Solr: Standalone embedded,
Standalone HTTP embedded, SolrCloud embedded, and perhaps eventually (not now)
"external" that could be used for e.g. docker or bin/solr.). The test case
would choose a specific type if it really cares but otherwise the choice is by
system property or finally randomly but biased to fast standalone embedded.
TBD wether this SolrProvider is a JUnit Rule but I'd prefer to start this way.
Alternatively, SolrTestCase in particular would provide methods for it, similar
to how SolrCloudTestCase offers a Builder and some utility methods. Main thing
is that it's opt-in; some simple unit tests don't even need Solr. This
functionality may borrow ideas & code from SolrCloudTestCase,
SolrJettyTestBase, and EmbeddedSolrServerTestBase. Eventually those classes
should change to use this SolrProvider. I personally have conceptually done
this task in some shape or form twice including just recently, thus I elect to
do this task now.
(B) Move the "good parts" of SolrTestCaseJ4 (STCJ4) to SolrTestCase (STC), it's
superclass, and consider STCJ4 deprecated. The "bad parts" of STCJ4 is the
TestHarness instance and thus all the methods that indirectly touch it. And
all the XML specific methods. I don't see the point of what we have today
wherein we have STC and STCJ4 thus this plan involves migrating to STC as the
new common base class -- the one we've had all along but barely knew it :-).
Changes should be small enough such that 3rd party solr-test-framework users
won't have to change in 8.x. Intermediate base classes (e.g.
SolrCloudTestCase) should migrate over to subclass STC. Ideally as many
subclasses of STCJ4 should switch to STC as is easy to do so.
It'd be nice if (A) is done first but it doesn't strictly matter. Once (A) is
done, the reach of (B) can extend to more tests. For example,
EmbeddedSolrServerTestBase must stick with STCJ4 until it has a SolrProvider to
switch to.
Any opinions here or shall I commence? I'm itching to start on a SolrProvider.
Obviously I'll show a PR to show how it's used, perhaps by a few converted
tests to show the gist.
> 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
>
> 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)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
