Watin Tests fail on CC.Net

Question

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?

Answer 1

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.

Answer 2

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.