[
https://issues.apache.org/jira/browse/SOLR-11872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16351053#comment-16351053
]
Hoss Man commented on SOLR-11872:
---------------------------------
{quote}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,
{quote}
I'd go even farther and say Ideally it should be possible for a test to say
"using confgiset=XXX, give me a {{SolrClient}}, i don't care what type" for
tests that want to verify that the updates/queries/asserts they run behave
consistently regardless of whether they are used against a single node/core, or
a cloud cluster with that collection using 1 shard, or 10 shards.
Having that, and having explicit asserts of the *expected* behavior (regardless
of shard count) would be vastly superior to a lot of our existing "distributed"
tests that just assert the response bodies of 2 identical queries done in
paralell to single/multi-node solr instance "match" – w/o ever verifying that
those responses contain anything of substance (let alone the _correct_
substance)
{quote}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.
{quote}
I can confirm i wrote all of those methods way, way, way back in the Solr 1.0
days when XML was the only way to talk to Solr. And while I generally agree
with you on this point (and would love to see methods like delI, delQ, & adoc
be phased out in favor of "short hand macros" that do similar things but return
actual UpdateRequest objects for passing to a SolrClient) I would like to point
out that one advantage of things like assertQ and the use of xpaths is that I
find it helps me write assertions much less verbosely then when i write Cloud
based tests of similar functionality – the trade off being that then you have
to know xpath, and for people who _don't_ intimately understand the syntax,
that brevity can be a hinderance to understanding/maintaining those tests.
I guess my point is that as we look towards ways to re-write tests using "real"
SolrJ supported {{SolrClient}} based APIs, and start looking at what some
"real" converted tests would actually look like, it would be worth while to
constantly keep an eye out for what kinds of helper functionality we might want
to include in our tests base classes to reduce the brevity needed when drilling
down into response documents to assert expected results. (But alas, i don't
have any concrete suggestions on what that might look like at this point)
----
{quote}Refactor and document... How to use the new refactored version should be
covered in the Ref Guide. ...
{quote}
_*Whoa...*_ I strongly disagree with this idea: the ref guide is for _end
users_ of solr – not java developers maintaining Solr tests or attempting to
subclass test framework base classes to write their own unit tests. This is
exactly what javadocs are for. If something doesn't seem like a good fit for a
specific classes javadoc, it should got in the package javadocs. (Or worst case
scenerio in {{./doc-files}} w/ a link from the relevant package/class/method
javadocs.)
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
