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

Port BasicNavigationBar.CodeSpit to the new test harness #57738

Merged
merged 5 commits into from
Nov 22, 2021

Conversation

sharwell
Copy link
Member

@sharwell sharwell commented Nov 12, 2021

Fixes #57719

@azure-pipelines
Copy link

Azure Pipelines successfully started running 4 pipeline(s).

@sharwell sharwell force-pushed the vs-extension-testing branch from ed556ec to ac28bdd Compare November 16, 2021 17:32
@sharwell sharwell marked this pull request as ready for review November 16, 2021 17:33
@sharwell sharwell requested a review from a team as a code owner November 16, 2021 17:33
internal async Task SendAsync(params object[] keys)
{
// AbstractSendKeys runs synchronously, so switch to a background thread before the call
await TaskScheduler.Default;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does SendKeys not need to run on the main thread then? It seems like its calling native code so I would have assumed it did

Copy link
Member Author

@sharwell sharwell Nov 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does SendKeys not need to run on the main thread then?

➡️ No. Eventually we'll have a proper async implementation here, but for now it's reusing some synchronous code from the old harness, and we can't block the main thread while that code runs.


var expectedCaretMarkupEndIndex = expectedCaretIndex + "$$".Length;

var expectedTextBeforeCaret = expectedText.Substring(0, expectedCaretIndex);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit - maybe have a small helper to extract the text w/out the $$ since it looks like you do it here and on line 129

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

➡️ It looks like this is cleaned up a bit in a pull request I'm submitting after this one, so I'll leave it here for now.

riid = typeof(IVsCodeWindow).GUID;
if (ErrorHandler.Failed(frame.QueryViewInterface(ref riid, out ppvObject)) || ppvObject == IntPtr.Zero)
{
return null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it be useful at all to have logs on failure cases here, or do the dumps typically contain all the information we'd need to verify which of these error cases we're hitting?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

➡️ It definitely wouldn't hurt, especially considering the next like after calling TryGetCodeWindow is always Assumes.Present. For now I'm OK keeping this form for two reasons:

  1. This code historically has not failed (copied from older harness)
  2. In the event of failure, we'll get a message saying IVsCodeWindow was expected but not available, and at that point it would be easy to update the implementation to better explain the point of failure

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the event of failure, we'll get a message saying IVsCodeWindow was expected but not available, and at that point it would be easy to update the implementation to better explain the point of failure

taht wfm. it's generally waht i've done when there are issues and the logs aren't sufficient.

await ExpandNavigationBarAsync(index: 2, cancellationToken);
}

public async Task ExpandNavigationBarAsync(int index, CancellationToken cancellationToken)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make private?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

➡️ Eliminated the intermediate callers and left this public

return await GetNavigationBarItemsAsync(index: 2, cancellationToken);
}

public async Task<ImmutableArray<string>> GetNavigationBarItemsAsync(int index, CancellationToken cancellationToken)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make private?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

➡️ Eliminated the intermediate callers and left this public

var itemIndex = await GetNavigationBarItemIndexAsync(index, item, cancellationToken);
if (itemIndex < 0)
{
throw new ArgumentException($"Could not find '{item}' in combobox");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you have this report the set of items that were there?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

➡️ Now using Assert.Contains on the failure path

await JoinableTaskFactory.SwitchToMainThreadAsync(cancellationToken);

var margin = await GetNavigationBarMarginAsync(textView, cancellationToken);
return margin.GetFieldValue<List<ComboBox>>("_combos");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well that's terrifying :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

➡️ Copied from old test harness. Happy to use a new approach if we find one.

return margin.GetFieldValue<List<ComboBox>>("_combos");
}

private async Task<UIElement?> GetNavigationBarMarginAsync(IWpfTextView textView, CancellationToken cancellationToken)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good god.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

who do we send feedback to that VS/editor needs a proper, resilient, testing API so we can do this sort of validation without this stuff?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe @AmadeusW ?

lineText = lineText.Trim();
lineTextBeforeCaret = lineTextBeforeCaret.TrimStart();
lineTextAfterCaret = lineTextAfterCaret.TrimEnd();
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

something feels weird here, but i can't put my finger on it. I can't determine why we would have different logic on how to trim the whitespace depending on where the caret is... i do not like this, and it feels to me that some bug is lurking within this.

Copy link
Member Author

@sharwell sharwell Nov 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

➡️ trimWhitespace is a bad idea all around in these tests. I'll take this opportunity to remove it.

@CyrusNajmabadi
Copy link
Member

So what'st he core change(s) here that makes the new test better than teh previous one? thanks!

@sharwell sharwell force-pushed the vs-extension-testing branch from ac28bdd to 72ee59c Compare November 17, 2021 20:51
@sharwell sharwell force-pushed the vs-extension-testing branch from f962a07 to 30d2570 Compare November 17, 2021 21:00
@sharwell
Copy link
Member Author

So what'st he core change(s) here that makes the new test better than teh previous one? thanks!

This is covered by the PR summary in #57626

Fixes a failure to wait for asynchronous operations following a
selection in the navigation bars.

Fixes dotnet#57719
if (Version.Parse("17.1.31916.450") > await TestServices.Shell.GetVersionAsync(cancellationToken))
{
// Workaround for extremely unstable async lightbulb prior to:
// https://devdiv.visualstudio.com/DevDiv/_git/VS-Platform/pullrequest/361759
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we track removing this somehow?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code will disable itself at the appropriate time when integration test machines update, so I probably wouldn't bother tracking separately. If we file an issue, it will likely just end up in the backlog and never get seen again, where it may or may not be updated after someone eventually removes this block.

I'd probably take a different approach if this was production code.

{
_ = cancellationToken;

return Task.CompletedTask;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did i miss where this is implemented somewhere?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this is a placeholder for now.

Copy link
Member

@CyrusNajmabadi CyrusNajmabadi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small bits of feedback. but nothing that woudl block this.

@sharwell sharwell merged commit 5a99085 into dotnet:main Nov 22, 2021
@sharwell sharwell deleted the vs-extension-testing branch November 22, 2021 16:25
@ghost ghost added this to the Next milestone Nov 22, 2021
@allisonchou allisonchou modified the milestones: Next, 17.1.P2 Nov 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Flaky Test] Roslyn.VisualStudio.IntegrationTests.VisualBasic.BasicNavigationBar.CodeSpit
4 participants