lucene-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (Jira)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-11872) Refactor test infra to work with a managed SolrClient; ditch TestHarness
Date Tue, 12 Nov 2019 00:01:00 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org


Mime
View raw message