colvinco commented on PR #3023: URL: https://github.com/apache/solr/pull/3023#issuecomment-2779015426
Thanks for the feedback @gerlowskija. Okay yep lets get something in and iterate on the rest of it. I will do a bit of cleanup, raise some issues under [SOLR-15734](https://issues.apache.org/jira/browse/SOLR-15734) for the bugs I've found so far and then I'm happy for you to polish the set of tests that you think are best to start with, thank you. > One tradeoff I guess is whether we want the test to be explicit about the HTTP details (the path, method, request body format, etc.), or whether it should use the SolrJ classes that we're auto-generating for the v2 APIs. > > The former approach asserts that the API looks exactly the way we want it to. The latter approach loses that explicitness by abstracting it behind client objects, but it tests the client and server code both which is nice. This is always a bit of a dilemma isn't it; how far do you trust that the implementation and spec align and is it worth the effort of doing things exhaustively? The "raw" approach is good for asserting the API shape, as you say. But obviously testing the client code is also a good thing. Perhaps the "best" solution is a hybrid approach where the requests are made using the client, but with some interception to assert that the request details match the expected "raw" details... but perhaps that's overkill here and better suited to individual endpoint tests (or unit tests for the client) rather than the smoke test? -- 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: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
