dsmiley commented on code in PR #4721:
URL: https://github.com/apache/solr/pull/4721#discussion_r3750952710


##########
solr/test-framework/src/java/org/apache/solr/SolrTestCaseJ4.java:
##########
@@ -1048,7 +1052,7 @@ public static <T> String assertThatJQ(SolrQueryRequest 
req, String message, Matc
       String response;
       boolean failed = true;
       try {
-        response = h.query(req);
+        response = h.query(handler, req);

Review Comment:
   I see you are updating many of this methods to pass the handler to 
`TestHarness.query`.  Why not update TestHarness in one spot instead of all 
these callers?



##########
solr/test-framework/src/java/org/apache/solr/SolrTestCaseJ4.java:
##########
@@ -1310,6 +1315,37 @@ public static SolrQueryRequest req(SolrParams params, 
String... moreParams) {
     return new SolrQueryRequestBase(h.getCore(), mp);
   }
 
+  /**
+   * Generates a SolrQueryRequest representing the specified path and query 
params
+   *
+   * <p>Path information is used by {@link #assertQ(SolrQueryRequest, 
String...)} and similar
+   * helpers to look up the request handler to invoke. When used with these 
helpers, typically only
+   * the requestHandler path segment need by provided ("/select", "/export", 
etc.)
+   *
+   * @see #req(String...)
+   */
+  public static SolrQueryRequest reqWithPath(String path, String... params) {

Review Comment:
   nice.
   FWIW I find `params` to be easy and I like the explicitness of separation 
with other params.  So if you were to simply have a `req(String,SolrParams)`  
(caller in practice then uses `params(...)` -- IMO that'd be fine.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to