How can I run UI tests with FlaUI on a remote machine whilst not RDP'd into it?

Question

We have some UI tests that use FlaUI to automate interaction with the windows UI.

When we run these tests on the build server, they fail to interact with the UI unless someone is connected via RDP.

The error we get from the tests is just a Could not send mouse input. ErrorCode: 5

The machine is set up to log in a user on startup and if we log in to an RDP session as that user and 'watch' the tests then they run ok and can interact with the desktop. As soon as we disconnect that user then they stop being able to interact again.

We are running the tests via NCrunch grid nodes, using NCrunch grid node console app, which starts on log in (ie its not running as a service so it can interact with the desktop).

Is there some way to make the tests run in a way that means we don't have to watch them continuously?

Answer 1

If you simulate a mouse click, there has to be an active desktop session (https://github.com/Roemer/FlaUI/wiki/FAQ#how-can-i-run-flaui-tests-on-a-build-serveragent).

You have two options: test without mouse clicks (use UIA patterns) or ensure an active desktop session for the build agent. As stated in the FAQ, make sure the session is not closed after disconnecting RDP by running tscon 1 /dest:console

Answer 2

As far as I remember, you can invoke events on the controls instead of simulating them with the mouse. It is different as the events are injected. This applies not just in TestStack.White adaptation, but in the most robot frameworks. So what was and is the motivation behind using the mouse?

When the JQuery came to Javascript, among other things it changed paradigm how items are referenced. But it also reduced the amount of code you need to write, create a utility method and change:

FindFirstChild(cf => cf.ByAutomationId("RedButton")).AsButton().Click();

to something shorter, for example:

_.Find<Button>("RedButton").Click();

Inadvertently you remove one layer of abstraction, make them more readable, runs faster, does not depend on screen resolution or dpi, etc.

One thing I would try if previous was not applicable - run the NCrunch Grid implementation in a virtual machine. I mean, in theory, it could work.