[
https://issues.apache.org/jira/browse/SOLR-17344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897499#comment-17897499
]
Christos Malliaridis commented on SOLR-17344:
---------------------------------------------
I could not say that commons-cli is rock-solid. It provides in my opinion too
much flexibility that can result to unexpected outcomes. There are situations
where a long option can be used with single-dash and a short option with
double-dash, or the fact that you can write single-dash options together and I
believe there is also option guessing where you don't have to provide the
entire long option (might be wrong on that), allows may invalid inputs.
What you are requesting here makes sense to me and would be great to introduce
if the "option randomization" does not need more testing than our CLI code.
With the whole migration we managed to reduce and merge many options, reducing
the chances of mistakes.
A theoretical implementation of mine would require us to define constraints
between short and long options, and a test would then just randomly put a few
of them together. Valid and invalid combinations may also be tested that way.
> 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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
