[
https://issues.apache.org/jira/browse/SOLR-17344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867824#comment-17867824
]
Jason Gerlowski commented on SOLR-17344:
----------------------------------------
bq. sort of getting the "this is a lot of work..." feeling... since this is for
code that is going to be removed in 10x, maybe it's just not worth it.
If we choose not to do this, that's fine. I agree it's a lot of work, so this
feels like a "Wish" type of ticket if there ever was one.
But nothing about this is 9.x or 10.x specific. At least as far as I know, no
one has proposed removing all short-opts or all long-opts. Users will continue
to be able to choose between "-c" and "--collection", so it makes sense at some
level to test that Solr handles both of those correctly.
bq. testing of "-" and "–" is just us testing commons-cli code!
True. Definitely not worth being exhaustive in testing different dash
characters, or in making sure commons-cli accepts both single-dash and
double-dash longopts. Though I think you could still justify a single unit
test that would break on a commons-cli upgrade, if that library ever changed
its default behavior.
But I disagree with what I think is your implication here, that only the
shell-based parsing is worth validating. Even assuming commons-cli is
rock-solid, there's tons of opportunity for bugs to creep in by our mis-using
it. It'd be very easy to typo a long-opt name, or have some copy-paste error
in the CLI code that builds out these long "OptionsBuilder" chains.
Maybe those should be JUnit tests and not (the comparatively heavy) BATS. But
it makes sense to validate somewhere IMO.
> Randomize short/long opts usage in Java-based CLI tests
> -------------------------------------------------------
>
> Key: SOLR-17344
> URL: https://issues.apache.org/jira/browse/SOLR-17344
> Project: Solr
> Issue Type: Sub-task
> Components: scripts and tools
> Affects Versions: main (10.0)
> Reporter: Jason Gerlowski
> Priority: Minor
>
> We have a decent suite of Java tests that validate "bin/solr" usage,
> including (but not limited to):
> * AuthToolTest
> * CreateToolTest
> * DeleteToolTest
> * PackageToolTest
> * HealthcheckToolTest
> * SolrCLIZkToolsTest
> Each of these tests triggers a tool with a (mostly hardcoded) set of
> string-literal parameters, e.g.
> {code}
> String[] args = {
> "auth",
> "enable",
> "-z",
> cluster.getZkClient().getZkServerAddress(),
> "--auth-conf-dir",
> dir.toAbsolutePath().toString(),
> "--solr-include-file",
> solrIncludeFile.toAbsolutePath().toString(),
> "-credentials",
> "solr:solr",
> "--block-unknown",
> "true"
> };
> assertEquals(0, runTool(args));
> {code}
> Randomizing the parameter names in these invocations would give us better
> coverage, and increase our confidence when making changes to the CLI syntax
> (like that done in SOLR-16824)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
