lucene-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Gerlowski (Jira)" <>
Subject [jira] [Commented] (SOLR-11872) Refactor test infra to work with a managed SolrClient; ditch TestHarness
Date Wed, 27 Nov 2019 16:56:00 GMT


Jason Gerlowski commented on SOLR-11872:

Sounds like a reasonable plan of attack to me.  I'm excited to see what this will look like.

> Refactor test infra to work with a managed SolrClient; ditch TestHarness
> ------------------------------------------------------------------------
>                 Key: SOLR-11872
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          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