-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Conversation
Azure Pipelines successfully started running 4 pipeline(s). |
ed556ec
to
ac28bdd
Compare
internal async Task SendAsync(params object[] keys) | ||
{ | ||
// AbstractSendKeys runs synchronously, so switch to a background thread before the call | ||
await TaskScheduler.Default; |
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.
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
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.
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); |
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.
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
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.
➡️ 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; |
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.
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?
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.
➡️ 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:
- This code historically has not failed (copied from older harness)
- 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
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.
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) |
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.
make private?
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.
➡️ Eliminated the intermediate callers and left this public
return await GetNavigationBarItemsAsync(index: 2, cancellationToken); | ||
} | ||
|
||
public async Task<ImmutableArray<string>> GetNavigationBarItemsAsync(int index, CancellationToken cancellationToken) |
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.
make private?
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.
➡️ Eliminated the intermediate callers and left this public
src/VisualStudio/IntegrationTest/New.IntegrationTests/InProcess/EditorInProcess.cs
Show resolved
Hide resolved
var itemIndex = await GetNavigationBarItemIndexAsync(index, item, cancellationToken); | ||
if (itemIndex < 0) | ||
{ | ||
throw new ArgumentException($"Could not find '{item}' in combobox"); |
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.
can you have this report the set of items that were there?
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.
➡️ Now using Assert.Contains
on the failure path
src/VisualStudio/IntegrationTest/New.IntegrationTests/InProcess/EditorInProcess.cs
Show resolved
Hide resolved
await JoinableTaskFactory.SwitchToMainThreadAsync(cancellationToken); | ||
|
||
var margin = await GetNavigationBarMarginAsync(textView, cancellationToken); | ||
return margin.GetFieldValue<List<ComboBox>>("_combos"); |
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.
well that's terrifying :)
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.
➡️ 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) |
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.
good god.
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.
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?
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.
Maybe @AmadeusW ?
lineText = lineText.Trim(); | ||
lineTextBeforeCaret = lineTextBeforeCaret.TrimStart(); | ||
lineTextAfterCaret = lineTextAfterCaret.TrimEnd(); | ||
} |
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.
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.
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.
➡️ trimWhitespace
is a bad idea all around in these tests. I'll take this opportunity to remove it.
So what'st he core change(s) here that makes the new test better than teh previous one? thanks! |
ac28bdd
to
72ee59c
Compare
f962a07
to
30d2570
Compare
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 |
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.
can we track removing this somehow?
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.
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; |
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.
did i miss where this is implemented somewhere?
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.
No, this is a placeholder for now.
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.
small bits of feedback. but nothing that woudl block this.
Fixes #57719