views:

1786

answers:

4

I'm running Watin tests with xUnit on CC.Net under Windows Server 2003.

I have lots of tests that all run fine on development boxes with TestDriven.Net and on the server with the xUnit gui app. However, when CC.Net runs the tests (as part of an MSBuild task) the function

ie.ContainsText("some text to find");

never returns the expected value. Other functions and properties on the IE object appear to work fine: Button(...).Click(), TextBox(...).Value, etc.

I am aware that the service account needs "Allow service to interact with the desktop".

I have tried this running CC service under Local System and local Administrator. The administrator account just hangs and never appears to finish running the tests (though it does create an instance of the iexplorer.exe process.

Is this an issue with permissioning on the server, or have I left something out of the configuration?

A: 

I've received a couple of suggestions offline:

  1. Attempt running the tests with msbuild on the server.
  2. Try starting CC.Net from the console instead of as a service.

Will edit with results.

EDIT:

Results:

  1. I am fully able to run the tests with msbuild on the server.
  2. When I run ccnet.exe from the command line the tests run fine. However, when I setup a task to start ccnet.exe from the command line on startup, the tests hang and never finish (eventually timing out).

Partial workaround is to run the command line executable on a session that never dies. I really don't like this solution though, so any further input would be appreciated.

Joel Potter
+1  A: 

Watin relies on browser automation to do it's job, thus the "allow service to interact with desktop" setting.

When Watin tries to run it will do so under the service account not the desktop that's currently logged in, and since it's going to spin up IE it's possible that the account you're running Watin under hasn't actually started IE itself before and it could be sitting in the initial startup sequence for IE where it prompts for settings and all that hoo-hah.

Also, if I recall correctly, the interact with desktop setting requires an active login to interact with. If no one is logged in at the time there's going to be nothing for the service to talk to and it's not going to create a new desktop for you.

Richard Banks
Hence my problem. Whether using the service, or running manually, an active session must be maintained on the integration server. Is there no way around this?
Joel Potter
Not that I know of. Sorry :-(
Richard Banks
+7  A: 

We just finished figuring out how to work around this problem. We now have watin tests running through CruiseControl.net running as a service.

We need our cc.net service to run as a specific user in order to access the website we are testing due to the way the security is set up. Since the service is running as a domain user the 'Allow user to interact with desktop' checkbox is disabled on the service security tab. We don't want to just run the command process from an always logged in user because we want the process to start automatically on reboot. Now we have figured out

The way we worked around this was by first creating a batch file to call the nunit-console.exe. Parameters to nunit-console.exe are passed to the batch file as parameters which then passes the parameters on. The second, and last, line of the batch file returns the return code returned from nunit-console.exe. The batch file essentially looks like this:

 nunit-console.exe %1 %2
 exit /b %ERRORLEVEL%

The number of parameters you pass through to nunit-console may be different based on your needs.

We are using nant for our builds, so then we replaced our existing nant task to call nunit-console with an exec task that calls cmd.exe that looks like this:

   <exec program="cmd.exe" failonerror="true">
   <arg value="/interactive" />
   <arg value="/c" />
   <arg value="[batch file name]" />
   <arg value="[parameter one value]" />
   <arg value="[parameter two value" />
   </exec>

I don't know what the same task would look like in msbuild but I'm sure you can look it up. The ultimate result is essentially a command that looks like this:

   cmd.exe /interactive /c [batch file name] [parameter one value] [parameter two value]

Alternatively, you could use nant and just create msbuld nant tasks to call your existing builds.

The '/interactive' parameter to cmd.exe is the key, it runs the batch file on a process that has permission to interact with the desktop. I'm actually not positive if the '/c' parameter is required, but it is working as it is. We are still telling nunit to log the results to the same xml file so our merge task didn't need to change and the reporting of the test results to cruise control is working great.

Brett
Brilliant! Created a batch file to call msbuild with just the Test target (/t:Test) and executed it using an exec task from ccnet. All the other targets are still running on an msbuild for simplicity. Works like charm.
Joel Potter
A: 

When I need to keep an active session on a machine I've been using Caffeine:

http://www.softpedia.com/get/Others/Miscellaneous/Caffeine.shtml

Jason