Erick Erickson commented on SOLR-11872:

bq:  I think our end users are almost always developers of one level or 

This is not true in my experience. I interact with a lot of organizations where 
they're using Solr without writing a single line of Java code. And even in the 
organizations where there are _some_ devs, after they get things working the 
project is often thrown over the wall to the operations people who want to do 
things like create collections, add replicas, change the schema and re-index, 
troubleshoot performance, troubleshoot why queries aren't returning expected 
results etc.. You know, keep Solr actually running day in and day out. All 
without necessarily knowing how to _read_ Java, much less write unit tests.

Now that said, for a dev to try to start developing Solr code, writing plugins, 
whatever is more difficult than it needs to be. "Dive in to the code and figure 
it out" is the advice I often have to give. "Start with a unit test" is another 
way to go. It would make a lot of sense to have a "Developer's Guide" aimed at, 
well, developers _in addition to_ the end-user Reference Guide. _That's_ where 
this kind of documentation should be done, not intermixed with the rest of the 
Reference Guide.

Organizationally I don't particularly care if we have two separate guides or 
they're two clearly separate halves of a single large. I _do_ care that we 
don't conflate the two; these are two very different audiences. I'm pretty sure 
there's content in the Reference Guide that would be a better fit in a 
Developer's Guide as well.

> 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

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to