You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2017/12/12 00:56:00 UTC

[jira] [Resolved] (SOLR-11575) Cleanup Java Snippets in "Using SolrJ" ref-guide page

     [ https://issues.apache.org/jira/browse/SOLR-11575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hoss Man resolved SOLR-11575.
-----------------------------
       Resolution: Implemented
         Assignee: Hoss Man
    Fix Version/s: 7.3
                   master (8.0)

Thanks Jason, these edits were great!

FYI, made one addition change...

{noformat}
+    expectLine("Found "+NUM_LIVE_NODES+" live nodes");
...
-    assertEquals(NUM_LIVE_NODES, liveNodes.size());
+    print("Found " + liveNodes.size() + " live nodes");
{noformat}

bq. I put the print-assertion utility functions in the test class itself, which isn't the most re-usable.  We can put it somewhere more re-usable, ...

If/when we decide we want the same mock {{print(String)}} method in another test class we can consider refactoring it -- but the main thing to remember is that "{{print(...)}}" is just what semed to make the most sense for these particula asserts.  It could have just as easily been a mock {{processResults(SolrDocument)}} method.  Down the road, we might want other snippets that use a mocked out {{SolrClient}} that asserts it's given the requests it expects, or a mocked out {{SolrParams}} class that asserts it gets the values the test expects.

The important thing is that we can focus on the snippets making sense in the context of the docs, and mocking whatever parts we need to ensure that the code in the snippets does what hte docs say they do -- even if those mocks are different between different tests.



> Cleanup Java Snippets in "Using SolrJ" ref-guide page
> -----------------------------------------------------
>
>                 Key: SOLR-11575
>                 URL: https://issues.apache.org/jira/browse/SOLR-11575
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>    Affects Versions: master (8.0)
>            Reporter: Jason Gerlowski
>            Assignee: Hoss Man
>            Priority: Trivial
>             Fix For: master (8.0), 7.3
>
>         Attachments: SOLR-11575.patch, SOLR-11575.patch
>
>
> Hoss pointed out on SOLR-11032 that some of the Java snippets don't do a great job of looking like
> bq. "real code" a user might do something with in an app.
> Particularly, the snippets show how to obtain certain SolrJ objects, but they don't show readers what they can/should do with those objects.  The snippets might be more useful to readers if they printed information returned in the SolrJ object as a result of each API call.  Hoss specifically suggested setting up a print-asserter, which would appear to be a normal print-statement in the ref-guide snippet, but double as an assertion in the JUnit test where the snippet lives.
> This JIRA involves giving that a shot.  It might make sense to figure this out before pulling more Java snippets into the build (as suggested in SOLR-11574).  On the flip side, extracting more snippets into the build might inform a better, consistent format/pattern for the snippets.  So these stories are related, but maybe not strict dependencies of one another.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org