[Open Discussion] Consistency and Test Cases for Mesheryctl (Meshery CLI)

Meshery
,
1

Improving the consistency and test cases for Mesheryctl (Meshery CLI) is crucial for enhancing the user experience and ensuring reliability. Here are a few ideas to maintain consistency and categorize them into groups for which we can write test cases and for which we can’t.

Ideas for Maintaining Consistency

  1. Case Insensitive Flags
  2. Suggestions for Wrong Inputs
  3. Consistent Help Messages
  4. Graceful Error Handling
  5. Auto-Completion Support
  6. Support for Abbreviations
  7. Default Values
  8. Verbose and Quiet Modes
  • Case Insensitive Flags
    • Ensure that commands recognize flags regardless of their case.
    • Example: mesheryctl start --config FILE and mesheryctl start --Config FILE should work the same.
  • Suggestions for Wrong Inputs
    • Provide suggestions for misspelled commands or flags.
    • Example: Typing mesheryctl staart should suggest Did you mean 'start'?
  • Consistent Help Messages
    • Verify that help messages follow a consistent format across all commands.
    • Example: mesheryctl help should display uniform help messages for all subcommands.
  • Graceful Error Handling
    • Check that errors are handled gracefully and meaningful error messages are provided.
    • Example: If a required configuration file is missing, the error message should clearly indicate the issue.
  • Default Values
    • Ensure that commands use default values when optional parameters are not provided.
    • Example: Running mesheryctl start without specifying a config file should use a default config if available.
  • Verbose and Quiet Modes
    • Test that commands respect verbose and quiet mode flags.
    • Example: mesheryctl start --verbose should provide detailed output, whereas mesheryctl start --quiet should minimize the output.
2

I wonder which if any of these should be or are already reflected in this guide - Contributing to Meshery CLI | Meshery

3

We have some items listed on Contributing to Meshery CLI.
The items such as Auto-Completion Support and Support for Abbreviations are not explicitly mentioned.

1 Like
4

Regarding the default values example of running mesheryctl start without specifying a config file should use a default config if available, mesheryctl not only does produces a new config file (meshconfig), but also prompts the user so as to ensure clarity as to what is going on and what is required to use mesheryctl. Yes, default values as a broad concept is ideal, while at the same time caution should be exercised to avoid being presumptuous, and in effect, over-optimizing and experience, when the most appropriate behavior is to prompt the user with a question. Providing default answers in those prompts is a helpful UX convention. mesheryctl has existing examples of prompting users and suggesting a default answer (kubernetes) when a user doesn’t designate which platform (docker or kubernetes) to which they are targeting their Meshery deployment.

Here’s encouragement to see that the CLI contributing guide is updated to include these best practices.

I propose a change to the Verbose and Quiet Modes suggestion, moving from “modes” to flags:

  1. Control over verbosity to either increase user’s comprehension as the behavior of the CLI given lots of contextual output to avoid annoying experienced users with fluff is ideal, using a flag like -v, -vv, -vvv.

  2. Separately, I’ll suggest that facilitating silent answers through flags (not a mode) increases Meshery CLI’s script-ability, which is ideal to the extent that users might rather script over mesheryctl versus scripting over REST or GraphQL APIs.

Apologies - I only read these two suggestions. I’ve run out of time.