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

ParseSplitPaneIntoArgs unit test is failing #4437

Closed
j4james opened this issue Feb 1, 2020 · 3 comments
Closed

ParseSplitPaneIntoArgs unit test is failing #4437

j4james opened this issue Feb 1, 2020 · 3 comments
Assignees
Labels
Area-CodeHealth Issues related to code cleanliness, linting, rules, warnings, errors, static analysis, etc. Area-Commandline wt.exe's commandline arguments Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Product-Terminal The new Windows Terminal.
Milestone

Comments

@j4james
Copy link
Collaborator

j4james commented Feb 1, 2020

Environment

Windows build number: Version 10.0.18362.535
Windows Terminal version (if applicable): Commit 55b6388

Steps to reproduce

  1. Build the OpenConsole solution.
  2. Run the unit tests with the runut.cmd script.

Expected behavior

All the tests should pass.

Actual behavior

The CommandlineTest::ParseSplitPaneIntoArgs test fails on line 593 with the message:

Error: Verify: AreEqual(SplitState::Vertical, myArgs.SplitStyle()) - Values (1, 4294967295) [File: \terminal\src\cascadia\LocalTests_TerminalApp\CommandlineTest.cpp, Function: TerminalAppLocalTests::CommandlineTest::ParseSplitPaneIntoArgs, Line: 593]
EndGroup: TerminalAppLocalTests::CommandlineTest::ParseSplitPaneIntoArgs [Failed]

That particular error looks to me like a mistake in the test itself. If the command line doesn't include a specific style, I would expect the style to be SplitState::Automatic. I'm guessing this is the result of a change in behavior as the code evolved. And I believe the tests on line 653 and line 707 will fail for the same reason.

Even with those cases fixed, though, there is still a failure which I think is an indication of a real bug in the code. The test on line 633 is failing because it's expecting the style to be Vertical but the return value is Automatic. The code that is to blame is in the AppCommandlineArgs::_buildSplitPaneParser method:

if ((*_horizontalOption || *_verticalOption) && (_splitHorizontal))
{
if (_splitHorizontal)
{
args->SplitStyle(SplitState::Horizontal);
}
else if (_splitVertical)
{
args->SplitStyle(SplitState::Horizontal);
}
}

There are two problems with this code. The first is that the initial branch isn't even passed unless _splitHorizontal is true, so the _splitVertical case is never handled. The second is that even with that fixed, the _splitVertical case will end up setting the style to Horizontal rather than Vertical.

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Feb 1, 2020
@DHowett-MSFT DHowett-MSFT added Area-CodeHealth Issues related to code cleanliness, linting, rules, warnings, errors, static analysis, etc. Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Feb 7, 2020
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Feb 7, 2020
@DHowett-MSFT
Copy link
Contributor

Yanking triage- i hit this as well, thanks for filing a followup

@DHowett-MSFT DHowett-MSFT added this to the Terminal v1.0 milestone Feb 7, 2020
@DHowett-MSFT
Copy link
Contributor

I've put a test bug into v1.0 because it's in a feature we added and are shipping, and we darn well better make sure it works right.

@cinnamon-msft cinnamon-msft added the Area-Commandline wt.exe's commandline arguments label Feb 19, 2020
@zadjii-msft zadjii-msft self-assigned this May 8, 2020
@zadjii-msft
Copy link
Member

Hey I just ran this locally and it looks like we must have fixed this recently. Hard to say for sure, but I bet it was back when we made auto the default behavior.

Fortunately with #6992 set up, we'll be more diligent about these tests in the future. Thanks!

@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label Aug 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-CodeHealth Issues related to code cleanliness, linting, rules, warnings, errors, static analysis, etc. Area-Commandline wt.exe's commandline arguments Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Product-Terminal The new Windows Terminal.
Projects
None yet
Development

No branches or pull requests

4 participants