Running UI automation tests on build server

Question

We use UI Automation and Nunit to create tests UI tests for WPF application. We've created tests that work fine when you run them from a local machine. Those tests never run successfully on our build server (using TeamCity). Build always hang after opening application window. But if I am logged in (remote desktop), on our build server all UI Automation tests also run successfully. So I am guessing that it probably has something to do with running active windows session. Any ideas how to convince our build server to create active windows session or any other solutions for making those tests run on build server?

Answer 1

Build always hang after opening application window.

Tests that instantiate the UI? That's not going to work, e.g. if you get a modal dialog the build will hang. This is the reason the MVP pattern was invented, to isolate the active presentation code from a concrete view.

Are you using a mock view in your automated tests?

Answer 2

You don't have many options. I will list the two I know, the most preferred option first:

• Set up a virtual machine on your build server. Your builds execute in the virtual machine. You can lock the host (aka your buildserver) keeping things secure.
• Keep someone logged on all the time. This offcourse creates a security problem. You can alleviate this problem a little by removing the mouse, keyboard and the screen and only access the buildserver through RDP or something similar.

---

Edit

Take a look at this TestComplete FAQ item: Can TestComplete execute scripts when the computer is locked?

Answer 3

It definatley sounds like you need to run your tests with an interactive session as opposed to a service. Adding the "Allow Service to interact with desktop" might help, but this is not supported in Vista any more apparently.

If you can run your builds interactivley as a command line, not a serivice that should work too.

We used to run our UIAutomation tests using the visual studo 2008 load agent to distribute them, running as a command line tool on VM's with no problem.

I also agree that you probably should't be running UI tests on a build server a part of your daily build.

Answer 4

OK, I'm just guessing here.

Try and run the TeamCity service with a local build server user instead of the system account. Maybe you have to login with that account once, before starting a new build.