UI Tests only run at 100% DPI

[michael-hawker]

Describe the bug

@azchohfi had discovered that our UI Tests assume there's a 100% DPI set for them to run on. The InputHelper is moving in absolute pixels, but the app is looking for the adjusted movement.

Alex has applied a fix in the winui branch, @RosarioPulella can you look at translating that back to our UWP AppService in the main branch? Thanks! Reach out to Alex if you need more info.

Steps to Reproduce

Steps to reproduce the behavior:

1. Set Monitor DPI to something other than 100%
2. Run full build in commandline
3. Run UI Tests
4. Fail

Expected behavior

Tests can run at any resolution.

[Rosuavio]

Interestingly enough, on my laptop the recommended is 125%, and on main under 100%, 125% is the test pass and under 150% and 175% the test fail.

I cant seem to be able to build the winui branch, but the only DPI related change I can see is that there is a way to retrieve the DPI into the test method, but the test does not seem to use the DPI, so I can't see how it handles the DPI better.

Either way, I will work on getting the DPI threw the AppService.

[Rosuavio]

Also I have to say, our usage of ProtoBufs in the winui branch looks nice. We could bring that code into main, making one less thing to merge from the winui branch and so we don't have to maintain two ways to communicate between the test app and the driver.

[Rosuavio]

I cant seem to be able to build the winui branch ...

I think it is my system.

[azchohfi]

I didn't solve the problem on the test itself, I've only started the work.
Unfortunately, I don't think we can use the protobuf solution in main since it runs inside the sandbox, and I don't think it would be available to be connected from the tests.

[Rosuavio]

Okay that clarifies things, I'll just add the "get dpi" to the service and figure out the rest for the API dependent tests. I wonder if there is a way to not need API dependent code in the tests methods, but that can be figured out later.

I cant help but to wonder if we should keep the assumption that the test run under 100% DPI. If some tests need DPI specific code but we don't test on multiple DPIs then there is sure to be new code that would need DPI specific code that passes CI and gets merged without it.

I will try to investigate a solution that does not require code in each test method.

[azchohfi]

I believe we need to fix this... Or else we force anyone that wants to contribute to the toolkit to use 100% dpi (to run the tests locally).

[Rosuavio]

But without running the UI test in CI at multiple DPIs (which could take a lot more time in CI), future PRs could bring in tests that fail on other DPIs. If we can't find a global fix, we can fix the test we have now and fix any test methods as we discover they don't work on other DPIs.