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












6















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?










share|improve this question

























  • 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
















6















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?










share|improve this question

























  • 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














6












6








6


1






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?










share|improve this 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?







ui-automation ncrunch flaui ncrunch-grid






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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



















  • 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












3 Answers
3






active

oldest

votes


















1





+500









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






share|improve this answer
























  • 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



















1














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.






share|improve this answer































    0














    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.






    share|improve this answer























      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
      });


      }
      });














      draft saved

      draft discarded


















      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









      1





      +500









      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






      share|improve this answer
























      • 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
















      1





      +500









      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






      share|improve this answer
























      • 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














      1





      +500







      1





      +500



      1




      +500





      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






      share|improve this answer













      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







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Jan 16 at 12:53









      Markus DreschMarkus Dresch

      1,545318




      1,545318













      • 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



















      • 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

















      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













      1














      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.






      share|improve this answer




























        1














        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.






        share|improve this answer


























          1












          1








          1







          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.






          share|improve this answer













          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 22 at 6:58









          Sam HolderSam Holder

          26.7k1079151




          26.7k1079151























              0














              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.






              share|improve this answer




























                0














                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.






                share|improve this answer


























                  0












                  0








                  0







                  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.






                  share|improve this answer













                  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.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jan 19 at 14:07









                  MargusMargus

                  13.8k104492




                  13.8k104492






























                      draft saved

                      draft discarded




















































                      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.




                      draft saved


                      draft discarded














                      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





















































                      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







                      Popular posts from this blog

                      Liquibase includeAll doesn't find base path

                      How to use setInterval in EJS file?

                      Petrus Granier-Deferre