[
https://issues.apache.org/jira/browse/SOLR-11872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16351458#comment-16351458
]
Gus Heck commented on SOLR-11872:
---------------------------------
Ok, that's fair, my perspective is probably skewed by things I have been
involved in. I did have one client who was using PHP for indexing, but mostly
my work has been with teams of java folks, or with me as "the guy". I don't
care much if it's separate or segregated, I just think it ought to exist at a
level beyond javadocs, somewhere where examples are easy to read/maintain and
people don't have to dig to find it. Package level javadocs, while a good idea
in theory are so rarely done well that I hardly ever look at them. 90% of the
time it's just blank anyway, so often I forget they even exist.
> 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
> 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
