Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Organize CLI help text in categories #1277

Closed
eNeRGy164 opened this issue Oct 24, 2020 · 1 comment · Fixed by #1699
Closed

Organize CLI help text in categories #1277

eNeRGy164 opened this issue Oct 24, 2020 · 1 comment · Fixed by #1699
Labels
🚀 Feature request New feature or request

Comments

@eNeRGy164
Copy link
Contributor

The current set of options for Stryker.NET is huge, resulting in a very large help text and it's hard to find settings you might be interested in.

I know #578 is about modifying the way of using options, and I have looked at it but this is a very large task and I didn't dare to start on this as most CLI libraries for .NET are all a little bit different as Stryker is doing things at the moment.
In the meantime, users are not helped. Therefore, I suggest to at least improve the readability of the help text.

I looked at the library currently used for options (McMaster.Extensions.CommandLineUtils) and it's fairly easy to overwrite the HelpTextGenerator

Locally I have added a category to each option (with my limited understanding of these options) and I think this improves the readability quite a bit
I also added a white line between options. Sometimes it's hard to recognize the text is already related to the next option.

An additional possibility is to add a weight (integer) to sort options within a category.

Example:
(Reduced some options for limit the length of this post)

❯ D:\github\stryker-net\src\Stryker.CLI\Stryker.CLI\bin\Debug\netcoreapp3.1\Stryker.CLI.exe --help
Stryker: Stryker mutator for .Net

Stryker mutator for .Net

Usage: Stryker [options]

Options:
  -cp|--config-file-path <path>                             Sets the config-file-path relative to current workingDirectory | stryker-config.json (default)

  -r|--reporters <reporters>                                Sets the reporter | Options[ (default)[ Progress, Html ], All, Dots, ClearText, ClearTextTree, Json, Dashboard, Baseline, (deprecated)
                                                            ConsoleProgressBar, (deprecated) ConsoleProgressDots, (deprecated) ConsoleReport ]]
                                                            This argument takes a json array as a value. Example: ['Progress', 'Html']

  -l|--log-level <logLevel>                                 Sets the console output logging level | Options [error, warning, info (default), debug, trace]

  -f|--log-file                                             Makes the logger write to a file (Logging to file always uses loglevel trace)


Build options:
  -p|--project-file <projectFileName>                       Used for matching the project references when finding the project to mutate. Example: "ExampleProject.csproj"

  -fte|--files-to-exclude <files-to-exclude>                (deprecated:Use '--mutate' instead.)Set files to exclude for mutation. Example:
                                                            ['C:/ExampleProject/Example.cs','C:/ExampleProject/Example2.cs']

  -m|--mutate <file-patterns>                               Allows to specify file that should in- or excluded for the mutations.
                                                            Use glob syntax for wildcards: https://en.wikipedia.org/wiki/Glob_(programming)
                                                            Use '!' at the start of a pattern to exclude all matched files.
                                                            Use '{<start>..<end>}' at the end of a pattern to specify spans of text in files to in- or exclude.
                                                            Example: ['**/*Service.cs','!**/MySpecialService.cs', '**/MyOtherService.cs{1..10}{32..45}']

...

Mutation options:
  -em|--excluded-mutations <mutators>                       The given mutators will be excluded for this mutation testrun.
                                                            This argument takes a json array as value. Example: ['string', 'logical']

  -im|--ignore-methods <methodNames>                        Mutations that would affect parameters that are directly passed into methods with given names are ignored. Example: ['ConfigureAwait',
                                                            'ToString']

...

Execution options:
  -dev|--dev-mode                                           Stryker automatically removes all mutations from a method if a failed mutation could not be rolled back
                                                            Setting this flag makes stryker not remove the mutations but rather break on failed rollbacks

  -ca|--coverage-analysis <mode>                            Use coverage info to speed up execution. Possible values are: off, all, perTest, perIsolatedTest.
                                                            - off: coverage data is not captured.
                                                            - perTest (Default): capture the list of mutations covered by each test. For every mutation that has tests, only the tests that cover this
                                                            mutation are tested. Fastest option.
                                                            - all: capture the list of mutations covered by each test. Test only these mutations. Fast option.
                                                            - perTestInIsolation: like 'perTest', but running each test in an isolated run. Slowest fast option.

...

Storage options:

...

Dashboard options:

...

If you like this idea, I can push my current code.

@eNeRGy164 eNeRGy164 added the 🚀 Feature request New feature or request label Oct 24, 2020
@rouke-broersma
Copy link
Member

@eNeRGy164 We are currently working on #578 and have already started a lot of the refactoring work.

I think categories are very helpful, but currently we're not even sure if we want to continue using CommandLineUtils because as you said it doesn't really quite fit our use case. That said we also couldn't yet find an alternative save for creating our own parser..

If you make your changes available we can take a look when the dust of the refactor has settled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🚀 Feature request New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants