Gus Heck commented on SOLR-11872:

{quote}_*Whoa...*_ I strongly disagree with this idea: the ref guide is for 
_end users_ of solr
People who write solrj code that interacts with solr sometimes use these test 
classes to power their own tests (running against their schema/etc)... I think 
our _end users_ are almost always developers of one level or another. How to 
quickly and easily write a unit test against an embedded solr (which class to 
use, what to do and not do, C/P starter example etc) is something I think a 
segment end users who use solrj might be happy to find in the ref guide, but 
sure better javadocs would be a great too. Personally for projects I do, I 
often pursue a more strictly unit test / mock object style, with fewer of these 
sorts of integrated tests (using embeded servers), but I know there are lots of 
folks who just love embedded server tests (for a variety of servers, not just 


> 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