-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Comments
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. |
See #1565 for some additional tips and link to an example. |
(Feel free to ask more questions, just pointing you in the right direction!) |
@shadowspawn gotcha! thanks for the clarification 👍 |
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:
myapp subcommand --init
(correctly passesinit
as argument to handler)myapp subcommand --other 1234
(correctly passesother
as argument to handler, but also includesinit
from first call)myapp subscommand
(passes previous values forinit
andother
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).The text was updated successfully, but these errors were encountered: