c07553cb57
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:
* [x] Doesn't close anything, this is just something I noticed.
* [x] Doesn't require docs to be updated, it's test fixes
* [x] 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 ccda434f69)
51 lines
1.9 KiB
C++
51 lines
1.9 KiB
C++
/*++
|
||
Copyright (c) Microsoft Corporation
|
||
Licensed under the MIT license.
|
||
|
||
Module Name:
|
||
- winrtTaefTemplates.hpp
|
||
|
||
Abstract:
|
||
- This module contains common TAEF templates for winrt-isms that don't otherwise
|
||
have them. This is very similar to consoleTaefTemplates, but this one presumes
|
||
that the winrt headers have already been included.
|
||
|
||
Author:
|
||
- Mike Griese 2021
|
||
|
||
--*/
|
||
|
||
#pragma once
|
||
|
||
// Thinking of adding a new VerifyOutputTraits for a new type? MAKE SURE that
|
||
// you include this header (or at least the relevant definition) before _every_
|
||
// Verify for that type.
|
||
//
|
||
// From a thread on the matter in 2018:
|
||
// > my best guess is that one of your cpp files uses a COORD in a Verify macro
|
||
// > without including consoletaeftemplates.hpp. This caused the
|
||
// > VerifyOutputTraits<COORD> symbol to be used with the default
|
||
// > implementation. In other of your cpp files, you did include
|
||
// > consoletaeftemplates.hpp properly and they would have compiled the actual
|
||
// > specialization from consoletaeftemplates.hpp into the corresponding obj
|
||
// > file for that cpp file. When the test DLL was linked, the linker picks one
|
||
// > of the multiple definitions available from the different obj files for
|
||
// > VerifyOutputTraits<COORD>. The linker happened to pick the one from the cpp
|
||
// > file where consoletaeftemplates.hpp was not included properly. I’ve
|
||
// > encountered a similar situation before and it was baffling because the
|
||
// > compiled code was obviously doing different behavior than what the source
|
||
// > code said. This can happen when you violate the one-definition rule.
|
||
|
||
namespace WEX::TestExecution
|
||
{
|
||
template<>
|
||
class VerifyOutputTraits<winrt::hstring>
|
||
{
|
||
public:
|
||
static WEX::Common::NoThrowString ToString(const winrt::hstring& hstr)
|
||
{
|
||
return WEX::Common::NoThrowString().Format(L"%s", hstr.c_str());
|
||
}
|
||
};
|
||
}
|