How can I run UI tests with FlaUI on a remote machine whilst not RDP'd into it?
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?
ui-automation ncrunch flaui ncrunch-grid
|
show 2 more comments
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?
ui-automation ncrunch flaui ncrunch-grid
do they stop running after a RDP session was closed or do they not even start to run at all when no RDP session is open?
– Markus Dresch
Jan 16 at 10:35
I have made some progress on this and have them able to run as long as no RDP session has been started, and they stop after an RDP session is connected and then disconnected.
– Sam Holder
Jan 16 at 12:36
1
How about this Remote Execution Guide?
– Vasily Ryabov
Jan 21 at 12:50
Are there physical monitors connected to the remote machine?
– Jared Beach
Jan 22 at 17:29
1
its a VM sitting in a room full of server racks, and mostly the issue is resolved now
– Sam Holder
Jan 22 at 17:56
|
show 2 more comments
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?
ui-automation ncrunch flaui ncrunch-grid
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?
ui-automation ncrunch flaui ncrunch-grid
ui-automation ncrunch flaui ncrunch-grid
edited Jan 15 at 18:18
Sam Holder
asked Jan 10 at 20:23
Sam HolderSam Holder
26.7k1079151
26.7k1079151
do they stop running after a RDP session was closed or do they not even start to run at all when no RDP session is open?
– Markus Dresch
Jan 16 at 10:35
I have made some progress on this and have them able to run as long as no RDP session has been started, and they stop after an RDP session is connected and then disconnected.
– Sam Holder
Jan 16 at 12:36
1
How about this Remote Execution Guide?
– Vasily Ryabov
Jan 21 at 12:50
Are there physical monitors connected to the remote machine?
– Jared Beach
Jan 22 at 17:29
1
its a VM sitting in a room full of server racks, and mostly the issue is resolved now
– Sam Holder
Jan 22 at 17:56
|
show 2 more comments
do they stop running after a RDP session was closed or do they not even start to run at all when no RDP session is open?
– Markus Dresch
Jan 16 at 10:35
I have made some progress on this and have them able to run as long as no RDP session has been started, and they stop after an RDP session is connected and then disconnected.
– Sam Holder
Jan 16 at 12:36
1
How about this Remote Execution Guide?
– Vasily Ryabov
Jan 21 at 12:50
Are there physical monitors connected to the remote machine?
– Jared Beach
Jan 22 at 17:29
1
its a VM sitting in a room full of server racks, and mostly the issue is resolved now
– Sam Holder
Jan 22 at 17:56
do they stop running after a RDP session was closed or do they not even start to run at all when no RDP session is open?
– Markus Dresch
Jan 16 at 10:35
do they stop running after a RDP session was closed or do they not even start to run at all when no RDP session is open?
– Markus Dresch
Jan 16 at 10:35
I have made some progress on this and have them able to run as long as no RDP session has been started, and they stop after an RDP session is connected and then disconnected.
– Sam Holder
Jan 16 at 12:36
I have made some progress on this and have them able to run as long as no RDP session has been started, and they stop after an RDP session is connected and then disconnected.
– Sam Holder
Jan 16 at 12:36
1
1
How about this Remote Execution Guide?
– Vasily Ryabov
Jan 21 at 12:50
How about this Remote Execution Guide?
– Vasily Ryabov
Jan 21 at 12:50
Are there physical monitors connected to the remote machine?
– Jared Beach
Jan 22 at 17:29
Are there physical monitors connected to the remote machine?
– Jared Beach
Jan 22 at 17:29
1
1
its a VM sitting in a room full of server racks, and mostly the issue is resolved now
– Sam Holder
Jan 22 at 17:56
its a VM sitting in a room full of server racks, and mostly the issue is resolved now
– Sam Holder
Jan 22 at 17:56
|
show 2 more comments
3 Answers
3
active
oldest
votes
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
I'm unfamiliar with the commandtscon 1 /dest:console
. If I run this then disconnect the RDP session will that ensure that the machine does not lock?
– Sam Holder
Jan 22 at 6:59
that's exactly what it does, yes
– Markus Dresch
Jan 28 at 7:17
add a comment |
So I have made this work. Mainly I followed the instructions here but I also disabled ServerManager from starting up when the user logs in in TaskScheduler.
The company policy also prevents machines from not locking so we have a powershell script which presses numlock twice every minute to prevent the desktop from locking.
There were also issues with the desktop being too small when the default user logs in which also prevented things from being clicked.
add a comment |
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.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54136379%2fhow-can-i-run-ui-tests-with-flaui-on-a-remote-machine-whilst-not-rdpd-into-it%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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
I'm unfamiliar with the commandtscon 1 /dest:console
. If I run this then disconnect the RDP session will that ensure that the machine does not lock?
– Sam Holder
Jan 22 at 6:59
that's exactly what it does, yes
– Markus Dresch
Jan 28 at 7:17
add a comment |
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
I'm unfamiliar with the commandtscon 1 /dest:console
. If I run this then disconnect the RDP session will that ensure that the machine does not lock?
– Sam Holder
Jan 22 at 6:59
that's exactly what it does, yes
– Markus Dresch
Jan 28 at 7:17
add a comment |
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
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
answered Jan 16 at 12:53
Markus DreschMarkus Dresch
1,545318
1,545318
I'm unfamiliar with the commandtscon 1 /dest:console
. If I run this then disconnect the RDP session will that ensure that the machine does not lock?
– Sam Holder
Jan 22 at 6:59
that's exactly what it does, yes
– Markus Dresch
Jan 28 at 7:17
add a comment |
I'm unfamiliar with the commandtscon 1 /dest:console
. If I run this then disconnect the RDP session will that ensure that the machine does not lock?
– Sam Holder
Jan 22 at 6:59
that's exactly what it does, yes
– Markus Dresch
Jan 28 at 7:17
I'm unfamiliar with the command
tscon 1 /dest:console
. If I run this then disconnect the RDP session will that ensure that the machine does not lock?– Sam Holder
Jan 22 at 6:59
I'm unfamiliar with the command
tscon 1 /dest:console
. If I run this then disconnect the RDP session will that ensure that the machine does not lock?– Sam Holder
Jan 22 at 6:59
that's exactly what it does, yes
– Markus Dresch
Jan 28 at 7:17
that's exactly what it does, yes
– Markus Dresch
Jan 28 at 7:17
add a comment |
So I have made this work. Mainly I followed the instructions here but I also disabled ServerManager from starting up when the user logs in in TaskScheduler.
The company policy also prevents machines from not locking so we have a powershell script which presses numlock twice every minute to prevent the desktop from locking.
There were also issues with the desktop being too small when the default user logs in which also prevented things from being clicked.
add a comment |
So I have made this work. Mainly I followed the instructions here but I also disabled ServerManager from starting up when the user logs in in TaskScheduler.
The company policy also prevents machines from not locking so we have a powershell script which presses numlock twice every minute to prevent the desktop from locking.
There were also issues with the desktop being too small when the default user logs in which also prevented things from being clicked.
add a comment |
So I have made this work. Mainly I followed the instructions here but I also disabled ServerManager from starting up when the user logs in in TaskScheduler.
The company policy also prevents machines from not locking so we have a powershell script which presses numlock twice every minute to prevent the desktop from locking.
There were also issues with the desktop being too small when the default user logs in which also prevented things from being clicked.
So I have made this work. Mainly I followed the instructions here but I also disabled ServerManager from starting up when the user logs in in TaskScheduler.
The company policy also prevents machines from not locking so we have a powershell script which presses numlock twice every minute to prevent the desktop from locking.
There were also issues with the desktop being too small when the default user logs in which also prevented things from being clicked.
answered Jan 22 at 6:58
Sam HolderSam Holder
26.7k1079151
26.7k1079151
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Jan 19 at 14:07
MargusMargus
13.8k104492
13.8k104492
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54136379%2fhow-can-i-run-ui-tests-with-flaui-on-a-remote-machine-whilst-not-rdpd-into-it%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
do they stop running after a RDP session was closed or do they not even start to run at all when no RDP session is open?
– Markus Dresch
Jan 16 at 10:35
I have made some progress on this and have them able to run as long as no RDP session has been started, and they stop after an RDP session is connected and then disconnected.
– Sam Holder
Jan 16 at 12:36
1
How about this Remote Execution Guide?
– Vasily Ryabov
Jan 21 at 12:50
Are there physical monitors connected to the remote machine?
– Jared Beach
Jan 22 at 17:29
1
its a VM sitting in a room full of server racks, and mostly the issue is resolved now
– Sam Holder
Jan 22 at 17:56