Running nunit UI tests that use Win32 API

Hello All,

I am trying to do low-level UI test automation similar to one described here:
http://msdn2.microsoft.com/en-us/magazine/cc163738.aspx.
To test a method that opens a message box, I call it from a different thread and use win32 API to click the message box away.
The test passes in nunit console, but fails in Team City. When running in nunit console, I am logged into my computer
and can watch the message box physically appear on the screen and then automatically disappear.
And in Team City everything runs "on the background", and the only information I get back is that the message box is not found.
Is there a better way to integrate UI testing into Team City? Is there a setting that would allow me to do this?

Thanks in advance. Alina.

5 comments

Having just installed on Win32, I can see that the Build Agent installs as a Windows Service under the LocalSystem account.

You might try changing the service to run under your own identity. Standard disclaimer: configuration changes like this one always raise the risk of causing other problems in the product and may even introduce security issues that were not in the product as-shipped.

If you're on Windows XP, do this: Start > Programs > Administrative Tools > Computer Management, open Services and Applications in the nav pane, then click Services. Scroll the list until you can see Team City Build Agent Service. Double click the row to display the properties dialog and click the Log On tab. Select the This Account radio button to enable the username and password text boxes and enter your own login information. OK the dialog box and then stop and start (or restart) the service using the context menu in the list pane or by opening the dialog box again and using its controls.

Now try your test. Please post back if it helps. - Jeff Berkowitz

0

Unfortunately, setting the login name on build agent did not work.

I think the issue is that TeamCity nunit launcher runs on the background and therefore
it fails to open a message box window. When I run the same test using nunit launcher myself
(as opposed to TeamCity running it automatically when necessary),
I can see the message box appear and disappear and the tests pass.

Thanks for your comment. Please let me know if you have any further ideas.

0

That's a shame. There may still be a simple workaround, but I don't know it.

Note to the JetBrains folks: on a previous project of mine (different employer), we developed a Windows Forms-based GUI that cooperated with a Windows Service. We had a number of product issues similar to this one (also with file permissions, details of how file sharing interacted with Windows Services on different versions and patch levels of Windows, etc.)

Finally we settled on having two modes of installation. In "mode 1" the background program installed as a Windows Service, so it could continue to run when nobody was logged in, but came with these various issues. In "mode 2", we just installed the program as an ordinary Windows .exe and put it in the Start folder. Of course this meant that it ended when the user logged out. But it solved a whole set of these desktop- and file-access permission issues.

It turned out to be very easy to have a single binary that figured out internally whether to run as a Service or as an ordinary .exe based on context - no command line options or such.

Anyway, just a thought.

0

Could you try to start agent via agent.bat script? This script is in the bin directory of the agent.

--
Pavel Sher

0

Hello Jeff and Pavel,

Thank you very much for your replies.
It turns out that there is a TeamCity property that can be set to make UI tests pass.
If you go to TeamCity Log On tab in the properties window (see Jeff's reply above on how to get there),
there is a checkbox that says: "Allow service to interact with desktop".
This check box needs to be checked, and then the UI tests pass just fine.

I am not sure whether this checkbox is checked by default (I did not install TeamCity myself).
And it is only allowed for log on as local system account. There may be some good reasons for this,
but it would be more convenient for my project if it was also allowed for a specific account log on.
Well, anyway it is good to have this option and I am definitely going to use it.

Thank you again for your responses. My special thanks to Jeff whose posting contained all the
necessary information to figure out the details.

Edited by: alina1 on May 6, 2008 6:34 PM

0

Please sign in to leave a comment.