-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Fix test hooks for CommandLineParameterParser
#13459
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My intention was to decouple completely the parser from other code - parser should only parse. I think it is better to move the ConsoleControl.SetConsoleMode() out to ConsoleHost and SettingsFile too.
Also I believe it is better to turn on a test hook only for test where it is used.
|
My idea is to make the parser self-contained as much as possible -- its properties shouldn't be changed from outside the parser except for test hooks. Specifically, _parser.ConfigurationName = CommandLineParameterParser.GetConfigurationNameFromGroupPolicy(); |
|
ConsoleHost is owner of the parser (s_cpp), it defines how use results of command line parsing so I believe all logic should be in ConsoleHost, not in the parser. |
|
I don't think it really matters to make |
Oh, I spent many time to debug new tests because the parser has side effects. If you catch the issue again it confirms that the design is not so good and the worst thing is that this again provokes the addition of workarounds not only in tests but also in the main code. This is what I tried to avoid in my PR. Sorry for long discussion. |
It reveals the fact that the code was not written in a testable way, and hence I added the constructor for testing purpose and the Again, I personally don't care that much to make the argument parser a pure parser without side effect, and it's likely we cannot hold that true in future changes, unless you can catch and review all subsequent changes to the argument parser :). For now, I care more about fixing the test failure in debug build, so I will just go with your approach for this PR :) |
To express a personal preference, I think:
With that said, I know we ultimately want to minimise code churn and maximise performance, so an "ideal" design may not be the right move here |
As side value, after decoupling the parser we can easy measure its performances with As side thought, we do xUnit tests based exclusively on SMA and we could test decoupling (independent from SMA) code in separate xUnit tests to check the algorithms used. |
|
The Windows test fails The link does not work https://www.microsoft.com/download/details.aspx?id=40855 I think it is important for Windows Installer. /cc @TravisEz13 @adityapatwardhan @SteveL-MSFT |
We're working on this. Unclear why it's failing |
|
@rjmholt I think this one is ready to merge. |
|
🎉 Handy links: |
PR Summary
xUnit tests fail when running with
Debugconfiguration after #11482. The failed tests are those related toWindowsStyle_With_Right_ValuebecauseConsoleControl.SetConsoleModeactually gets called during testing but there is no console window, so the assert fails.This PR moves the call to
ConsoleControl.SetConsoleModeout of the argument parser.PR Context
PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:or[ WIP ]to the beginning of the title (theWIPbot will keep its status check atPendingwhile the prefix is present) and remove the prefix when the PR is ready.