locked
Trying to drive Coded UI tests remotely with Psexec RRS feed

  • Question

  • I've been trying to drive my Code UI Test project remotely using Psexec with no success.  Is the scenario described below possible?  It certainly seems like it given that you can configure an agent to interact with the desktop.  

    I have a standard CUIT project which drives a UI.  The MMC to be more exact  I have a controller and agent installed on the target server which does function locally when used for a load test.  I have the agent configured to run as a process so that it can interact with the desktop. I created a batch on the target server which then calls mstest with an orderedtest as an argument.  For example:

    mstest.exe /testcontainer:my.oderedtest /testsettings:remote.testsettings (note that the remote.testsettings uses the local controller and agent)

    I then call the batch file from a remote server using Psexec. The call succeeds (i.e. I see mstest invoked) but it fails with "The test process exited unexpectedly - Unable to start the agent process"  I checked the agent status and don't see that it has even tried to process a test, so I don't think it's getting that far.  

    Is there something I'm missing from the equation?

     

     

     

    • Moved by Mathew Aniyan MSFT Monday, June 13, 2011 5:22 AM Question on mstest (From:Visual Studio UI Automation Testing (includes CodedUI))
    Saturday, June 11, 2011 4:20 PM

All replies

  • Hi,

    You can configure the agent with a controller and then start execution on the remote agent. Please refer http://blogs.msdn.com/b/amit_chatterjee/archive/2009/03/28/remote-execution-and-data-collection.aspx

    Thanks,

    Anuj

    Tuesday, June 14, 2011 3:49 PM
  • Anuj,

    I was able to get past the initial error by configuring the test settings to "remote".  Now I've run into something new.  

    The initial test is simply to start the UI, which fails with "Error calling Initialization method for test class DataProtection_Diano.BackupRuns: Microsoft.VisualStudio.TestTools.UITest.Extension.UITestException: Automation engine is unable to playback the test because it is not able to interact with the desktop. This could happen if the computer running the test is locked or it’s remote session window is minimized."  

    I've run the agent configuration tool and made sure it's set to run the agent as a process.  I do have both the controller and the agent running on the same server.  Is there a restriction on that configuration?  Also, I noticed that when managing the controller, the agent has an asterisk by the name.  I've not found any documentation describing the meaning of this.  It seems that maybe the agent is not even getting the job?

    Tuesday, June 14, 2011 9:05 PM
  • Stiga43,

    I have this same error you have.  Did you find  a solution to this step of setting remotely?

    Thanks

    Wednesday, June 29, 2011 8:16 PM
  • I have not.  The project got put on the back burner for a week or so, so I haven't had a chance to work with it anymore.  I'm also hoping Anuj will reply in a short period of time too.  Let me know if you come across anything.  
    Wednesday, June 29, 2011 11:15 PM
  • I was successful once turning a codedui into an executable, I am thinking to try that again and see if that matters.
    Thursday, July 21, 2011 10:11 PM
  • Daniel,

    Not sure I follow.  Are you saying that you built a .exe and the tests run standalone with that?

    Friday, July 22, 2011 3:59 PM
  • Yeah stand alone on a machine with VS2010 on it, but that was a while back and I wasn't able to do it now.  The library has changed or something.

    What I have decided to do to work around this is to have the program always running on the machine running the test, and control it through a database, with a loop, a stored proc and a sleep routine.  (not a timer though as that creates a different thread.)  This way I can run it on three or more machines without having to log into each.

    I dont want to use a test controller because I want it fully automated, including knowing which tests to run and where to run them when someone does a different action.  (Such as a deployment.)



    Monday, August 1, 2011 8:41 PM