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

Write a test that global parsing doesn't conflict with local parsing #59

Closed
2 tasks
chshersh opened this issue Aug 7, 2022 · 2 comments · Fixed by #88
Closed
2 tasks

Write a test that global parsing doesn't conflict with local parsing #59

chshersh opened this issue Aug 7, 2022 · 2 comments · Fixed by #88
Labels
cli-options CLI options, parsers good first issue Good for newcomers hacktoberfest https://hacktoberfest.com/ test

Comments

@chshersh
Copy link
Owner

chshersh commented Aug 7, 2022

Similar to #56

People shouldn't specify options that conflict with ours. But if they still do, it would be nice to know whether their parsing conflicts with ours. So I propose to add two tests and document their results in public API:

  • my-program --no-input when the custom parser specifies --no-input as well (ideally this should be checked by Tests for CLI #13)
  • my-program --no-input my-command --no-input is confusing but ideally should be parsed and return different results for different --no-input. If not, having a test is still good and documenting this behaviour is nice.
@chshersh chshersh added cli-options CLI options, parsers test good first issue Good for newcomers labels Aug 7, 2022
@chshersh chshersh moved this to Todo in Iris Project Sep 22, 2022
@chshersh chshersh added the hacktoberfest https://hacktoberfest.com/ label Sep 27, 2022
@zetkez
Copy link
Contributor

zetkez commented Oct 8, 2022

Hi, i want to take this one as my first task. I found a breaking case that is when the custom parser defines --no-input [TARGET] while being a mandatory option. Defined like this the app always displays the help/error message "expected: ...". I assume this is the second case of the listing above.
Should i still assume this as the wanted behavior? And does it make sense to add the tests before #67 as i would define custom CliEnvSettings with a custom parser?

@chshersh
Copy link
Owner Author

chshersh commented Oct 9, 2022

@zetkez Feel free to give it a go! All CLI tests can be found in this module (and can be added here for now):

I believe, it makes sense to test several combinations:

  • --no-input as an on-off flag
  • --no-input=[SOME_VALUE] as a flag that expects a value
  • my-command --no-input: when a custom command expects the same flag

Once we have these 3 test cases, we can improve the documentation to reflect this behaviour 🙂
The point of this issue is not to fix the behaviour but to discover what is the actual existing behavior and document it for our users.

Hope that helps!

@chshersh chshersh added this to the v0.1.0.0: Improved UX milestone Oct 10, 2022
zetkez pushed a commit to zetkez/iris that referenced this issue Oct 12, 2022
chshersh pushed a commit that referenced this issue Oct 13, 2022
Repository owner moved this from Todo to Done in Iris Project Oct 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli-options CLI options, parsers good first issue Good for newcomers hacktoberfest https://hacktoberfest.com/ test
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants