David Smiley created SOLR-11872:
-----------------------------------
Summary: 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
Security Level: Public (Default Security Level. Issues are Public)
Components: Tests
Reporter: David Smiley
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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
