lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <>
Subject [jira] [Commented] (SOLR-11872) Refactor test infra to work with a managed SolrClient; ditch TestHarness
Date Sat, 03 Feb 2018 04:33:00 GMT


Erick Erickson commented on SOLR-11872:

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

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:
>             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:
For additional commands, e-mail:

View raw message