Fix unittesting our `.xaml` classes (#4105)
## Summary of the Pull Request
New year, new unittests.
This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests.
## References
## PR Checklist
* [x] Closes #3986
* [x] I work here
* [x] is Tests
* [n/a] Requires documentation to be updated
* [x] **Waiting for an updated version of TAEF to be available**
## Detailed Description of the Pull Request / Additional comments
Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems.
This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year.
So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests.
Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in.
## Validation Steps Performed
ran the tests yo
2020-01-10 19:55:31 +01:00
|
|
|
|
<?xml version="1.0" encoding="utf-8"?>
|
|
|
|
|
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
|
|
|
|
|
<PropertyGroup Label="Globals">
|
|
|
|
|
<ProjectGuid>{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}</ProjectGuid>
|
2020-10-27 23:00:41 +01:00
|
|
|
|
<ProjectName>TestHostApp</ProjectName>
|
Fix unittesting our `.xaml` classes (#4105)
## Summary of the Pull Request
New year, new unittests.
This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests.
## References
## PR Checklist
* [x] Closes #3986
* [x] I work here
* [x] is Tests
* [n/a] Requires documentation to be updated
* [x] **Waiting for an updated version of TAEF to be available**
## Detailed Description of the Pull Request / Additional comments
Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems.
This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year.
So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests.
Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in.
## Validation Steps Performed
ran the tests yo
2020-01-10 19:55:31 +01:00
|
|
|
|
<RootNamespace>TestHostApp</RootNamespace>
|
|
|
|
|
<DefaultLanguage>en-US</DefaultLanguage>
|
|
|
|
|
<MinimumVisualStudioVersion>14.0</MinimumVisualStudioVersion>
|
|
|
|
|
<AppContainerApplication>true</AppContainerApplication>
|
2020-07-09 06:10:50 +02:00
|
|
|
|
<WindowsStoreApp>true</WindowsStoreApp>
|
Fix unittesting our `.xaml` classes (#4105)
## Summary of the Pull Request
New year, new unittests.
This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests.
## References
## PR Checklist
* [x] Closes #3986
* [x] I work here
* [x] is Tests
* [n/a] Requires documentation to be updated
* [x] **Waiting for an updated version of TAEF to be available**
## Detailed Description of the Pull Request / Additional comments
Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems.
This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year.
So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests.
Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in.
## Validation Steps Performed
ran the tests yo
2020-01-10 19:55:31 +01:00
|
|
|
|
<ApplicationType>Windows Store</ApplicationType>
|
|
|
|
|
<ApplicationTypeRevision>10.0</ApplicationTypeRevision>
|
|
|
|
|
<OutputSubDir>Tests\Data</OutputSubDir>
|
|
|
|
|
<UseWmXml>true</UseWmXml>
|
|
|
|
|
<ConfigurationType>Application</ConfigurationType>
|
2020-10-27 23:00:41 +01:00
|
|
|
|
<OpenConsoleCppWinRTProject>true</OpenConsoleCppWinRTProject>
|
Fix unittesting our `.xaml` classes (#4105)
## Summary of the Pull Request
New year, new unittests.
This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests.
## References
## PR Checklist
* [x] Closes #3986
* [x] I work here
* [x] is Tests
* [n/a] Requires documentation to be updated
* [x] **Waiting for an updated version of TAEF to be available**
## Detailed Description of the Pull Request / Additional comments
Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems.
This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year.
So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests.
Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in.
## Validation Steps Performed
ran the tests yo
2020-01-10 19:55:31 +01:00
|
|
|
|
|
|
|
|
|
<!--
|
|
|
|
|
These two properties are very important!
|
|
|
|
|
Without them, msbuild will stomp MinVersion and MaxVersionTested in the
|
|
|
|
|
Package.appxmanifest and replace them with whatever our values for
|
|
|
|
|
TargetPlatformMinVersion and TargetPlatformVersion are.
|
|
|
|
|
-->
|
|
|
|
|
<AppxOSMinVersionReplaceManifestVersion>false</AppxOSMinVersionReplaceManifestVersion>
|
|
|
|
|
<AppxOSMaxVersionTestedReplaceManifestVersion>false</AppxOSMaxVersionTestedReplaceManifestVersion>
|
|
|
|
|
|
|
|
|
|
</PropertyGroup>
|
|
|
|
|
|
|
|
|
|
<Import Project="$(SolutionDir)\common.openconsole.props" Condition="'$(OpenConsoleDir)'==''" />
|
|
|
|
|
|
|
|
|
|
<Import Project="$(OpenConsoleDir)\src\common.build.pre.props" />
|
|
|
|
|
|
|
|
|
|
<!-- This project is _heavily_ cribbed directly from the TAEF samples. In
|
|
|
|
|
order to avoid breaking this project, it's been left largely unmodified. The
|
|
|
|
|
only modifications are those near the bottom of the file:
|
|
|
|
|
* References to our dependent winrt projects (Connection, Settings, Control,
|
|
|
|
|
App)
|
|
|
|
|
* Manual copy steps to copy the actual test code (TerminalApp.LocalTests.dll)
|
|
|
|
|
and the dlls that TerminalConnection is dependent upon, but don't roll up
|
|
|
|
|
here for whatever reason.
|
|
|
|
|
-->
|
|
|
|
|
|
|
|
|
|
<!-- This is important: It somehow convinces the CI to not validate that
|
|
|
|
|
"taef.png" is actually in the package. taef.png will get copied to the
|
|
|
|
|
OutputPath when taef is run, but if this isn't set to false, then the CI
|
|
|
|
|
will try and make sure taef.png is in the OutputPath at build time.-->
|
2020-08-07 16:46:52 +02:00
|
|
|
|
|
Fix unittesting our `.xaml` classes (#4105)
## Summary of the Pull Request
New year, new unittests.
This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests.
## References
## PR Checklist
* [x] Closes #3986
* [x] I work here
* [x] is Tests
* [n/a] Requires documentation to be updated
* [x] **Waiting for an updated version of TAEF to be available**
## Detailed Description of the Pull Request / Additional comments
Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems.
This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year.
So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests.
Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in.
## Validation Steps Performed
ran the tests yo
2020-01-10 19:55:31 +01:00
|
|
|
|
<PropertyGroup Label="UserMacros">
|
|
|
|
|
<GenerateAppxPackageOnBuild>false</GenerateAppxPackageOnBuild>
|
|
|
|
|
</PropertyGroup>
|
2020-08-07 16:46:52 +02:00
|
|
|
|
|
Fix unittesting our `.xaml` classes (#4105)
## Summary of the Pull Request
New year, new unittests.
This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests.
## References
## PR Checklist
* [x] Closes #3986
* [x] I work here
* [x] is Tests
* [n/a] Requires documentation to be updated
* [x] **Waiting for an updated version of TAEF to be available**
## Detailed Description of the Pull Request / Additional comments
Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems.
This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year.
So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests.
Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in.
## Validation Steps Performed
ran the tests yo
2020-01-10 19:55:31 +01:00
|
|
|
|
<ItemDefinitionGroup>
|
|
|
|
|
<ClCompile>
|
|
|
|
|
<DisableSpecificWarnings>4453;%(DisableSpecificWarnings)</DisableSpecificWarnings>
|
|
|
|
|
<AdditionalIncludeDirectories>%(AdditionalIncludeDirectories)
|
|
|
|
|
;$(IntermediateOutputPath)
|
|
|
|
|
</AdditionalIncludeDirectories>
|
|
|
|
|
<PreprocessorDefinitions>INLINE_TEST_METHOD_MARKUP;%(PreprocessorDefinitions)</PreprocessorDefinitions>
|
|
|
|
|
</ClCompile>
|
|
|
|
|
<Link>
|
|
|
|
|
<AdditionalDependencies>$(AdditionalDependencies);windowsapp.lib</AdditionalDependencies>
|
|
|
|
|
<IgnoreAllDefaultLibraries>false</IgnoreAllDefaultLibraries>
|
|
|
|
|
</Link>
|
|
|
|
|
</ItemDefinitionGroup>
|
|
|
|
|
|
|
|
|
|
<ItemGroup>
|
|
|
|
|
<ClInclude Include="pch.h" />
|
|
|
|
|
<ClInclude Include="UnitTestApp.xaml.h">
|
|
|
|
|
<DependentUpon>UnitTestApp.xaml</DependentUpon>
|
|
|
|
|
</ClInclude>
|
|
|
|
|
</ItemGroup>
|
|
|
|
|
<ItemGroup>
|
|
|
|
|
<ApplicationDefinition Include="UnitTestApp.xaml">
|
|
|
|
|
<SubType>Designer</SubType>
|
|
|
|
|
</ApplicationDefinition>
|
|
|
|
|
</ItemGroup>
|
|
|
|
|
<ItemGroup>
|
|
|
|
|
<AppxManifest Include="Package.appxmanifest">
|
|
|
|
|
<SubType>Designer</SubType>
|
|
|
|
|
</AppxManifest>
|
|
|
|
|
</ItemGroup>
|
|
|
|
|
<ItemGroup>
|
|
|
|
|
<ClCompile Include="UnitTestApp.xaml.cpp">
|
|
|
|
|
<DependentUpon>UnitTestApp.xaml</DependentUpon>
|
|
|
|
|
</ClCompile>
|
|
|
|
|
<ClCompile Include="pch.cpp">
|
|
|
|
|
<PrecompiledHeader>Create</PrecompiledHeader>
|
|
|
|
|
</ClCompile>
|
|
|
|
|
</ItemGroup>
|
|
|
|
|
|
|
|
|
|
<!-- Reference all the WinRT projects that we want to role up into this test project. -->
|
|
|
|
|
<ItemGroup>
|
|
|
|
|
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\TerminalConnection\TerminalConnection.vcxproj">
|
|
|
|
|
<Project>{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}</Project>
|
|
|
|
|
</ProjectReference>
|
2020-12-11 22:34:57 +01:00
|
|
|
|
|
|
|
|
|
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\TerminalSettingsEditor\Microsoft.Terminal.Settings.Editor.vcxproj" />
|
2021-03-17 21:47:24 +01:00
|
|
|
|
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\TerminalControl\dll\TerminalControl.vcxproj" />
|
Fix unittesting our `.xaml` classes (#4105)
## Summary of the Pull Request
New year, new unittests.
This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests.
## References
## PR Checklist
* [x] Closes #3986
* [x] I work here
* [x] is Tests
* [n/a] Requires documentation to be updated
* [x] **Waiting for an updated version of TAEF to be available**
## Detailed Description of the Pull Request / Additional comments
Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems.
This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year.
So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests.
Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in.
## Validation Steps Performed
ran the tests yo
2020-01-10 19:55:31 +01:00
|
|
|
|
|
2020-08-21 00:44:37 +02:00
|
|
|
|
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\TerminalApp\dll\TerminalApp.vcxproj">
|
Fix unittesting our `.xaml` classes (#4105)
## Summary of the Pull Request
New year, new unittests.
This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests.
## References
## PR Checklist
* [x] Closes #3986
* [x] I work here
* [x] is Tests
* [n/a] Requires documentation to be updated
* [x] **Waiting for an updated version of TAEF to be available**
## Detailed Description of the Pull Request / Additional comments
Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems.
This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year.
So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests.
Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in.
## Validation Steps Performed
ran the tests yo
2020-01-10 19:55:31 +01:00
|
|
|
|
<Project>{ca5cad1a-44bd-4ac7-ac72-f16e576fdd12}</Project>
|
|
|
|
|
</ProjectReference>
|
|
|
|
|
|
2020-10-06 18:56:59 +02:00
|
|
|
|
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\TerminalSettingsModel\dll\Microsoft.Terminal.Settings.Model.vcxproj">
|
|
|
|
|
<Project>{CA5CAD1A-082C-4476-9F33-94B339494076}</Project>
|
|
|
|
|
</ProjectReference>
|
|
|
|
|
|
Fix unittesting our `.xaml` classes (#4105)
## Summary of the Pull Request
New year, new unittests.
This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests.
## References
## PR Checklist
* [x] Closes #3986
* [x] I work here
* [x] is Tests
* [n/a] Requires documentation to be updated
* [x] **Waiting for an updated version of TAEF to be available**
## Detailed Description of the Pull Request / Additional comments
Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems.
This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year.
So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests.
Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in.
## Validation Steps Performed
ran the tests yo
2020-01-10 19:55:31 +01:00
|
|
|
|
</ItemGroup>
|
|
|
|
|
|
|
|
|
|
<PropertyGroup>
|
|
|
|
|
<!-- Some helper paths to find our test code -->
|
|
|
|
|
<_TAEFPlatformName>$(Platform)</_TAEFPlatformName>
|
|
|
|
|
<_TAEFPlatformName Condition="'$(Platform)'=='Win32'">x86</_TAEFPlatformName>
|
|
|
|
|
</PropertyGroup>
|
|
|
|
|
|
|
|
|
|
<ItemGroup>
|
|
|
|
|
<Reference Include="Microsoft.VisualStudio.TestPlatform.TestExecutor.WinRTCore">
|
2021-03-30 12:58:11 +02:00
|
|
|
|
<HintPath>$(OpenConsoleDir)\packages\Microsoft.Taef.10.58.210305002\lib\Microsoft.VisualStudio.TestPlatform.TestExecutor.WinRTCore.winmd</HintPath>
|
Fix unittesting our `.xaml` classes (#4105)
## Summary of the Pull Request
New year, new unittests.
This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests.
## References
## PR Checklist
* [x] Closes #3986
* [x] I work here
* [x] is Tests
* [n/a] Requires documentation to be updated
* [x] **Waiting for an updated version of TAEF to be available**
## Detailed Description of the Pull Request / Additional comments
Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems.
This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year.
So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests.
Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in.
## Validation Steps Performed
ran the tests yo
2020-01-10 19:55:31 +01:00
|
|
|
|
<IsWinMDFile>true</IsWinMDFile>
|
|
|
|
|
|
|
|
|
|
<!-- This path is _relative to the .winmd_ -->
|
|
|
|
|
<Implementation>..\build\Binaries\$(_TAEFPlatformName)\TE.AppxUnitTestClient.dll</Implementation>
|
|
|
|
|
</Reference>
|
|
|
|
|
</ItemGroup>
|
|
|
|
|
|
2020-12-05 00:49:45 +01:00
|
|
|
|
<Import Project="$(OpenConsoleDir)\packages\Microsoft.UI.Xaml.2.5.0-prerelease.201202003\build\native\Microsoft.UI.Xaml.targets" Condition="Exists('$(OpenConsoleDir)\packages\Microsoft.UI.Xaml.2.5.0-prerelease.201202003\build\native\Microsoft.UI.Xaml.targets')" />
|
Fix unittesting our `.xaml` classes (#4105)
## Summary of the Pull Request
New year, new unittests.
This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests.
## References
## PR Checklist
* [x] Closes #3986
* [x] I work here
* [x] is Tests
* [n/a] Requires documentation to be updated
* [x] **Waiting for an updated version of TAEF to be available**
## Detailed Description of the Pull Request / Additional comments
Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems.
This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year.
So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests.
Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in.
## Validation Steps Performed
ran the tests yo
2020-01-10 19:55:31 +01:00
|
|
|
|
|
|
|
|
|
<Import Project="$(OpenConsoleDir)\src\common.build.post.props" />
|
|
|
|
|
|
2020-11-08 14:14:42 +01:00
|
|
|
|
<ItemGroup>
|
|
|
|
|
<TestDll Include="$(OpenConsoleCommonOutDir)\LocalTests_TerminalApp\TerminalApp.LocalTests.dll" />
|
|
|
|
|
<TestDll Include="$(OpenConsoleCommonOutDir)\LocalTests_SettingsModel\SettingsModel.LocalTests.dll" />
|
|
|
|
|
</ItemGroup>
|
|
|
|
|
|
|
|
|
|
<Target Name="AfterBuild" Inputs="@(TestDll)" Outputs="@(TestDll->'$(TargetDir)'\%(Filename)%(Extension)')">
|
Fix unittesting our `.xaml` classes (#4105)
## Summary of the Pull Request
New year, new unittests.
This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests.
## References
## PR Checklist
* [x] Closes #3986
* [x] I work here
* [x] is Tests
* [n/a] Requires documentation to be updated
* [x] **Waiting for an updated version of TAEF to be available**
## Detailed Description of the Pull Request / Additional comments
Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems.
This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year.
So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests.
Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in.
## Validation Steps Performed
ran the tests yo
2020-01-10 19:55:31 +01:00
|
|
|
|
|
2020-06-08 23:01:47 +02:00
|
|
|
|
<!-- Use this to auto-find all the dll's that TerminalConnection produces. We
|
|
|
|
|
don't roll these up automatically, so we'll need to copy them manually
|
|
|
|
|
(below)
|
|
|
|
|
|
|
|
|
|
The dependencies from TerminalConnection get rolled up in the
|
|
|
|
|
GetPackagingOutputs step, when it produces the "appx recipe". This means
|
|
|
|
|
they only show up when the build produces an AppX\ folder for either running
|
|
|
|
|
or packaging.
|
|
|
|
|
|
|
|
|
|
It is literally impossible to produce an AppX\ folder using MSBuild without
|
|
|
|
|
packaging an appx, and we don't want to do that anyway, so we use these copy
|
|
|
|
|
rules instead.
|
|
|
|
|
-->
|
|
|
|
|
<ItemGroup>
|
2020-10-27 23:00:41 +01:00
|
|
|
|
<TerminalConnectionDlls Include="$(OpenConsoleCommonOutDir)\TerminalConnection\*.dll"/>
|
2020-06-08 23:01:47 +02:00
|
|
|
|
</ItemGroup>
|
|
|
|
|
|
Fix unittesting our `.xaml` classes (#4105)
## Summary of the Pull Request
New year, new unittests.
This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests.
## References
## PR Checklist
* [x] Closes #3986
* [x] I work here
* [x] is Tests
* [n/a] Requires documentation to be updated
* [x] **Waiting for an updated version of TAEF to be available**
## Detailed Description of the Pull Request / Additional comments
Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems.
This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year.
So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests.
Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in.
## Validation Steps Performed
ran the tests yo
2020-01-10 19:55:31 +01:00
|
|
|
|
<!-- Copy the AppxManifest.xml to another file, because when TAEF is
|
|
|
|
|
deploying the app, it'll delete the AppxManifest.xml file from this
|
|
|
|
|
directory when it tries to clean up after itself. -->
|
|
|
|
|
<Copy SourceFiles="$(TargetDir)\AppxManifest.xml" DestinationFiles="$(TargetDir)\TestHostAppXManifest.xml" />
|
|
|
|
|
|
2020-11-08 14:14:42 +01:00
|
|
|
|
<!-- Copy all test code -->
|
|
|
|
|
<Copy SourceFiles="@(TestDll)"
|
|
|
|
|
DestinationFolder="$(TargetDir)"
|
|
|
|
|
UseHardLinksIfPossible="true"
|
|
|
|
|
SkipUnchangedFiles="true" />
|
2020-10-06 18:56:59 +02:00
|
|
|
|
|
Fix unittesting our `.xaml` classes (#4105)
## Summary of the Pull Request
New year, new unittests.
This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests.
## References
## PR Checklist
* [x] Closes #3986
* [x] I work here
* [x] is Tests
* [n/a] Requires documentation to be updated
* [x] **Waiting for an updated version of TAEF to be available**
## Detailed Description of the Pull Request / Additional comments
Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems.
This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year.
So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests.
Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in.
## Validation Steps Performed
ran the tests yo
2020-01-10 19:55:31 +01:00
|
|
|
|
<!-- Copy some dlls which TerminalConnection is dependent upon that didn't
|
|
|
|
|
get rolled up into this directory -->
|
|
|
|
|
<Copy SourceFiles="@(TerminalConnectionDlls)"
|
2020-11-08 14:14:42 +01:00
|
|
|
|
DestinationFolder="$(TargetDir)"
|
|
|
|
|
UseHardLinksIfPossible="true"
|
|
|
|
|
SkipUnchangedFiles="true" />
|
Fix unittesting our `.xaml` classes (#4105)
## Summary of the Pull Request
New year, new unittests.
This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests.
## References
## PR Checklist
* [x] Closes #3986
* [x] I work here
* [x] is Tests
* [n/a] Requires documentation to be updated
* [x] **Waiting for an updated version of TAEF to be available**
## Detailed Description of the Pull Request / Additional comments
Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems.
This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year.
So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests.
Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in.
## Validation Steps Performed
ran the tests yo
2020-01-10 19:55:31 +01:00
|
|
|
|
|
|
|
|
|
</Target>
|
|
|
|
|
</Project>
|