Question

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.

Was it helpful?

Solution

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.

OTHER TIPS

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top