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

Command instance re-using old arguments on subsequent calls in test env #1819

Closed
yamalight opened this issue Nov 9, 2022 · 4 comments
Closed

Comments

@yamalight
Copy link

I've encountered an odd behavior where subcommands in test env will re-use optional arguments from previous calls.
At the top level - you have a program and a subcommand with optional flags. Following calls behave oddly:

  1. Call myapp subcommand --init (correctly passes init as argument to handler)
  2. Call myapp subcommand --other 1234 (correctly passes other as argument to handler, but also includes init from first call)
  3. Call myapp subscommand (passes previous values for init and other instead of empty args)

Is this behavior intended? If yes, how would one reset args between tests? The only way I've found so far was to monkey-patch subcommand _optionValues which feels wrong 😅

I've created a small repro case in stackblitz: https://stackblitz.com/edit/node-nsyb1h?file=app.test.js
Calling npm test executes it.
Uncommenting monkey-patching in the last test case makes it behave as expected (i.e. not pass any args when none given to parse function).

@shadowspawn
Copy link
Collaborator

Thanks for the detail and example.

The short answer is make new Commands for each test. i.e. both program and subcommand.

The code isn't written to allow multiple calls to parse, and there isn't a routine to reset state.

@shadowspawn
Copy link
Collaborator

See #1565 for some additional tips and link to an example.

@shadowspawn
Copy link
Collaborator

(Feel free to ask more questions, just pointing you in the right direction!)

@yamalight
Copy link
Author

@shadowspawn gotcha! thanks for the clarification 👍
I'll close the issue since it's expected behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants