Conversation
| var dirtyModifier = await TestServices.Editor.GetDirtyIndicatorAsync(HangMitigatingCancellationToken); | ||
| Assert.Equal($"FileImplementation.cs{dirtyModifier}", await TestServices.Shell.GetActiveWindowCaptionAsync(HangMitigatingCancellationToken)); |
There was a problem hiding this comment.
There isn't a way to check the dirty modifier and base name separately?
There was a problem hiding this comment.
One could be created. There are several different approaches that would work, but for now this one seemed like the least amount of thinking work. 😂
| public async Task<string> GetDirtyIndicatorAsync(CancellationToken cancellationToken) | ||
| { | ||
| var version = await TestServices.Shell.GetVersionAsync(cancellationToken); | ||
| if (version < Version.Parse("17.2.32224.407")) |
There was a problem hiding this comment.
it looks like the PR added an option - to be resilient in case they change the default values for it, should we just have a helper that asserts the name is either dot or star?
There was a problem hiding this comment.
Interesting, this is a user-visible option too:
...VisualStudio/IntegrationTest/New.IntegrationTests/InProcess/FindReferencesWindowInProcess.cs
Show resolved
Hide resolved
Visual Studio can take a long time to start, which causes test runs to fail spuriously.
jasonmalinowski
left a comment
There was a problem hiding this comment.
Approving especially to get the 25 minute timeout bump done.
| } | ||
|
|
||
| builder.Append(" --blame-crash --blame-hang-dump-type full --blame-hang-timeout 15minutes"); | ||
| builder.Append(" --blame-crash --blame-hang-dump-type full --blame-hang-timeout 25minutes"); |
There was a problem hiding this comment.
As a request (but not in this PR, so we don't hold it up), let's get a comment here linking to a bug to track the slow starts. I'm thinking it might be always good that there's more or less a comment here pointing to what the "slow test" is if ever we needed to drop this; in hindsight I should have done that to start.
| await TestServices.Workspace.WaitForAllAsyncOperationsAsync( | ||
| new[] { FeatureAttribute.Workspace, FeatureAttribute.NavigateTo }, | ||
| cancellationToken); |
There was a problem hiding this comment.
Why the workspace wait after the command but not before?
There was a problem hiding this comment.
I was accounting for the possibility that navigation may be asynchronous. It may be possible to remove this; I'm not sure.
There was a problem hiding this comment.
Specifically, this was my new replacement for the following old code:
|
|
||
| public async Task GoToImplementationAsync(CancellationToken cancellationToken) | ||
| { | ||
| await TestServices.Shell.ExecuteCommandAsync(WellKnownCommands.Edit.GoToImplementation, cancellationToken); |
There was a problem hiding this comment.
Should this method switch to main thread first thing as the existing GoToBaseAsync does?
There was a problem hiding this comment.
Same Q for the GoToDefinitionAsync method above.
There was a problem hiding this comment.
➡️ No, these methods don't do any work with UI thread affinity that the caller is responsible for
Review commit-by-commit recommended