Thanks RosarioPulella for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌

Trying to figure out the necessary math for making the test work on other DPIs, the communication is working. I think though there might be no need for the test methods to know the DPI for the grid splitter tests. We could move the mouse to a target rather than a certain amount of pixels. I think that would be a cleaner solution and how I am trying to build the RangeSelector tests. @michael-hawker if there is a reason to use DragDistance rather than DragToTarget, let me know as I would much rather use DragToTarget and add a target item to the test env.

@RosarioPulella the GridSplitter sites between two columns or rows of a Grid so there isn't much else to interact with. We could try and have another element positioned in the Grid, but part of the tests are also trying to drag beyond the confines of the definitions to check bounds.

I'd worry that trying to add another element and dragging towards it (even if for the same behavior) may make it harder to connect what the test is doing with what it's trying to test? Thoughts?

You bring up some good points @michael-hawker. While I do think movement targets in the test env for the mouse to move towards could be just as clear as moving a certain distance in a direction, I think that since all the test share the same UI environment, keeping as much that is only relative to one test in that one test method rather then the ui env would let the test scale better.