This page contains recommendations of practitioners related to automated unattended runs of UIAutomation PowerShell Extensions.
The general rule
UIAutomation as well as other screen-related technologies of software testing and accessibility requires a user session. The session should be active, not locked (though UIAutomation shows signs of life, it gets many times slower), without screensaver.
We recommend you to use Windows
(there is a
Normal screen vs RDP
we discussed advantages and disadvantages of running UIAutomation via RDP connection or direct access to the host display.
Thanks to georgik
The problem is that when you are disconnecting an RDP session or even simply change the screen area, UIAutomation tests usually fail.
The solutions here are
1) to use the host screen directly or via virtualization client software
2) either use the seconds display.
Accordingly to our experience, using
Remote Desktop Connection Manager
on a separate monitor may help.
VMware Client Console
There is a problem with VMware Pointing Device. This driver should be uninstalled, otherwise all operations involving moving the cursor (for example, the Invoke-UIAcontrolClick uses the SetCursorPos API call to position the cursor in the geometrical center
of the control) will fail.
Hyper-V, XEN, etc
No information right now.
Running as a service
Because of security vulnerabilities, Microsoft put services into the
since Vista RTM. Therefore, there's no way to run UIAutomation or similar tests in a service session.
Manual interventions in tests
Though this is nonsence as an idea (who in the healthy mind would visit the screen of a host that run automated tests?), it's possible situation during test tailoring or replaying of problemous places of the test. What can we say? Please avoid any manual
intervention when you are seeing test that is running now. Some cmdlets have Win32 API calls inside that are vulnerable to the cursor postion.