[
https://issues.apache.org/jira/browse/SOLR-11575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265550#comment-16265550
]
Jason Gerlowski edited comment on SOLR-11575 at 11/24/17 11:04 PM:
-------------------------------------------------------------------
The attached patch changes many of the tests in
UsingSolrJRefGuideExamplesTest.java to use the print-based-assertion approach
that Hoss suggested back on SOLR-11032.
I switched the assertions over to being fake-print-driven if:
* the assertion was "doc-included" into the ref-guide, OR
* doing so improved the assertion itself (some assertions previously just
checked for String non-emptiness, but now check for specific values)
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, but to make
the best decision there it might be smart to figure out where else we might
have these "doc-included" Java snippets. I created SOLR-11574 to see what
other ref-guide snippets might be unit-testable earlier, which seems like a
good place to do that, if we don't want it blocking this JIRA. I'm also fine
holding up this JIRA until we answer the reuse question.
FYI [~hossman], as you requested this on 11032
was (Author: gerlowskija):
The attached patch changes many of the tests in
UsingSolrJRefGuideExamplesTest.java to use the print-based-assertion approach
that Hoss suggested back on SOLR-11032.
I switched the assertions over to being fake-print-driven if:
* the assertion was "doc-included" into the ref-guide, OR
* doing so improved the assertion itself (some assertions previously just
checked for String non-emptiness, but now check for specific values)
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, but to make
the best decision there it might be smart to figure out where else we might
have these "doc-included" Java snippets. I created SOLR-11574 to see what
other ref-guide snippets might be unit-testable earlier, which seems like a
good place to do that, if we don't want it blocking this JIRA. I'm also fine
holding up this JIRA until we answer the reuse question.
FYI [~hossman]
> 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
> Priority: Trivial
> Attachments: 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
