A bunch of test fixes

[zadjii-msft]

A bunch of our local tests regressed recently. I'm unsure as to when
this happened. Clearly, we all do a super good job of running these
tests 😄.

• I had to make sure the call to AppLogic::CurrentAppSettings was
  try/caught, because that doesn't work in the tests
• I had to make the Pointer* events take a weak pointer to the
  TerminalPage because for whatever reason, they'd be called at a
  weird point in the test init, causing the tests to fail. It was weird.
  Almost as if the TerminalPage had been released, but the test logs
  showed it hadn't barely been set up yet? Whatever, this fixes it.
• The VerifyCommandPaletteTabSwitcherOrder test needed to take a time
  out, for reasons that are not totally clear to me. That one was flakey
  and I hate it.

Checklist:

• Doesn't close anything, this is just something I noticed.
• Doesn't require docs to be updated, it's test fixes
• Yea, I ran the tests

/cc @Don-Vito: The FilteredCommandTests all crashed immediately for
me. I'm not sure what's causing that - I think everything we need for
those tests is set up right? The generated AppxManifest.xml had all
the right classes listed in it, I really can't be sure what was wrong
there. These tests aren't run in CI so it's not a super big deal, but I
thought I'd let you know.

(cherry picked from commit ccda434)

[Don-Vito]

@zadjii-msft - I will try to take a look. I didn't run them for a while as well. Is there any plan to fix the CI to run all tests?

[zadjii-msft]

Is there any plan to fix the CI to run all tests?

Yes, but IIRC there was some infrastructure reason as to why the LocalTests still couldn't run in the actual CI. Maybe it was just the pipeline took too long to run on every PR? I think that's what I'm getting from reading #6992. So I think there's a rolling build that does run the LocalTests, but it's not per-PR.

It actually looks like the rolling builds are broken too: https://dev.azure.com/ms/terminal/_build/results?buildId=139468&view=logs&j=20c53c45-6f0c-50af-9c69-e93710d9ccb1&t=10a580e5-4c97-5b69-8e02-8d961e3cb079

C:\Program Files\dotnet\sdk\5.0.103\MSBuild.dll -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,C:\Program Files\dotnet\sdk\5.0.103\dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,C:\Program Files\dotnet\sdk\5.0.103\dotnet.dll -maxcpucount -verbosity:m /binaryLogger:D:\a\1\s/RunTestsInHelix.x64.release.binlog /p:HelixBuild=139468.x64.release /p:Platform=x64 /p:Configuration=release /p:HelixType=test/devtest /p:TestSuite=DevTestSuite /p:ProjFilesPath=D:\a\1\a /p:rerunPassesRequiredToAvoidFailure=5 /p:IsExternal=true /p:Creator=Terminal /p:HelixTargetQueues=windows.10.amd64.client19h1.open.xaml D:\a\1\s\build\Helix\RunTestsInHelix.proj
D:\a\1\s\build\Helix\RunTestsInHelix.proj : error : Unable to find package Microsoft.DotNet.Helix.Sdk. No packages exist with this id in source(s): TerminalDependencies
D:\a\1\s\build\Helix\RunTestsInHelix.proj : error MSB4236: The SDK 'Microsoft.DotNet.Helix.Sdk' specified could not be found.
##[error]Error: The process 'C:\Program Files\dotnet\dotnet.exe' failed with exit code 1
Info: Azure Pipelines hosted agents have been updated and now contain .Net 5.x SDK/Runtime along with the older .Net Core version which are currently lts. Unless you have locked down a SDK version for your project(s), 5.x SDK might be picked up which might have breaking behavior as compared to previous versions. You can learn more about the breaking changes here: https://docs.microsoft.com/en-us/dotnet/core/tools/ and https://docs.microsoft.com/en-us/dotnet/core/compatibility/ . To learn about more such changes and troubleshoot, refer here: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting
##[error]Dotnet command failed with non-zero exit code on the following projects : D:\a\1\s\build\Helix\RunTestsInHelix.proj

/cc @miniksa

[miniksa]

Is there any plan to fix the CI to run all tests?

Yes, but IIRC there was some infrastructure reason as to why the LocalTests still couldn't run in the actual CI. Maybe it was just the pipeline took too long to run on every PR? I think that's what I'm getting from reading #6992. So I think there's a rolling build that does run the LocalTests, but it's not per-PR.

That was the reason. At the time, we were using build agents that were unable to run the sorts of packaged activations that we needed, so they had to go to a different pool of agents for testing. And that mechanism was substantially slower than the rest of the CI, so it was moved to rolling-build only.

It actually looks like the rolling builds are broken too: https://dev.azure.com/ms/terminal/_build/results?buildId=139468&view=logs&j=20c53c45-6f0c-50af-9c69-e93710d9ccb1&t=10a580e5-4c97-5b69-8e02-8d961e3cb079

FFFFFFFFFF. I'll look.

[miniksa]

Instead of a sleep which could vary in length, can we make an event or mutex or something above... dispatch it on a TestOnUIThread element after all the other tests in a lambda that does nothing but set/trigger it, and then wait here on it until it's triggered as the last queued packet on the UI thread? That would likely assure that the other events have propagated in a more reliable manner?

[zadjii-msft]

I would love to do that. Unfortunately, the event I'm waiting for here is "let XAML do it's thing". I'm not really sure there's a specific event I can wait for in this case 😕

[DHowett]

I hate that this is a workaround for test stuff being weird. The TerminalPage never goes away in common use, so we waste some cycles on every interaction to lock the weak ref.

[ghost]

Hello @DHowett!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[Don-Vito]

@zadjii-msft - I found the reason for FilteredCommand test failures: RPC_E_WRONG_THREAD 🤦 Committing.