[ https://issues.apache.org/jira/browse/SOLR-11872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626209#comment-17626209 ]
Joshua Ouma commented on SOLR-11872: ------------------------------------ Hi [~dsmiley] I'm interested in working on this project as an Outreachy intern. As part of the application process, applicants are required to submit a timeline of tasks for the 13 weeks internship period. To come up with the timeline we are advised to discuss with our mentors. The application closing period is approaching thus I would like to come up with the timeline. Are there specific tasks or factors that I should consider while coming up with the timeline? > 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 > Components: Tests > Reporter: David Smiley > Priority: Major > Labels: gsoc2021, mentor > > 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 (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org