views:

298

answers:

2

Question

What is the standard approach to solve timing problems in automated UI tests?

Concrete example

I am using Visual Studio 2010 and Team Foundation Server 2010 to create automated UI tests and want to check whether my application has really stopped running:

[TestMethod]
public void MyTestMethod()
{
    Assert.IsTrue(!IsMyAppRunning(), "App shouldn't be running, but is.");

    StartMyApp();
    Assert.IsTrue(IsMyAppRunning(), "App should have been started and should be running now.");

    StopMyApp();
    //Pause(500);
    Assert.IsTrue(!IsMyAppRunning(), "App was stopped and shouldn't be running anymore.");
}

private bool IsMyAppRunning()
{
    foreach (Process runningProcesse in Process.GetProcesses())
    {
        if (runningProcesse.ProcessName.Equals("Myapp"))
        {
            return true;
        }
    }
    return false;
}

private void Pause(int pauseTimeInMilliseconds)
{
     System.Threading.Thread.Sleep(pauseTimeInMilliseconds);
}

StartMyApp() and StopMyApp() have been recorded with MS Test Manager 2010 and reside in UIMap.uitest.

The last assert fails because the assertion is executed while my application is still in the process of shutting down. If I put a delay after StopApp() the test case passes.

The above is just an example to explain my problem. What is the standard approach to solve these kinds of timing issues? One idea would be to wait with the assertion until I get some event notification that my app has been stopped.

+1  A: 

It looks like you are trying to test an asynchronous interface. That doesn't work too well with automated testing. You should break it up into two tests. Each test should handle one side of the interface with the opposite side being mocked.

Dabowheel
Can you elaborate a bit? How would that look for the MyTestMethod example? Thanks.
Lernkurve
Since the function, StopMyApp, returns before it does what it supposed to do, you can't test it. You can only test code inside of StopMyApp. I can't tell you how to do that because I don't know what's inside it.
Dabowheel
Inside it is a piece of code generated by the Coded UI Test Builder. It just opens the File menu and clicks the Quit menu item.public void StopMyApp() { #region Variable Declarations WpfMenuItem uIExitMenuItem = this.UIActusWindow1.UIRadMenuMenu.UIFileMenuItem.UIExitMenuItem; #endregion // Click 'File' -> 'Exit' menu item Mouse.Click(uIExitMenuItem, new Point(92, 11)); }
Lernkurve
+1  A: 

You could add some synchronization to StopMyApp. If you attach to the Process object for your app, you can use Process.WaitForExit() to wait for program completion.

Tom E
+1 That's a pretty cool solution. Didn't know that. Works. Thanks.
Lernkurve