Integrate Uno.UI.RuntimeTests.Engine

[MartinZikmund]

As Labs are designed to be fully cross-platform, it would be great to run future runtime tests on all targets as part of CI. We have recently extracted the runtime tests engine used to verify both UI and non-UI features of Uno as a separate package that is reusable across all targets including UWP and WinAppSDK - https://github.com/unoplatform/uno.ui.runtimetests.engine . I would be glad to help out with integrating this!

[michael-hawker]

Background

Thanks @MartinZikmund, I've been looking at creating simple systems for us to write E2E tests using the MSTest framework in #183 that work for UWP and WinUI 3 using the built-in UWP Input Injection API. The OS in the VM should be patched now, so I'll be checking this there with WinUI 3 again soon.

We were using the TAEF framework before from the WinUI team, but it was a lot more complex to setup tests and run them in VS vs. the CI.

Now that Labs introduced the ability to just reference the XAML page, it integrates well with all the existing setup we've used in the past for basic UI testing in the Toolkit, but extends it to more directly engaged tests that require user interaction as well, but also still allowing complete testability/access to the results and control structures in the Visual Tree (vs. going through Automation tooling alone).

Questions

Is the Uno.UI.RuntimeTests.Engine more of a runner to allow the UWP based MSTests we'd already have to run against other platforms?

Or is it its own framework with own API to control Uno based apps?

In either case, sounds like we should chat a bit more sometime. Ping me on Discord and we can figure out a time that works.

FYI @Arlodotexe @niels9001

[jeromelaban]

Uno.UI.RuntimeTests.Engine is an in-app test runner, with features to enable uithread affinity, async, fullscreen only and other capabilities for tests to use the current UI tree.

It's currently using its own custom runner, because mstest was not easily extractible a few years back, but maybe now it may be useable in such a context.

It's also a source nuget package to avoid tricky dependencies with runtime/binaries versions.