One of the most frequent questions regarding Coded UI Tests goes like this - “I have a test running very well on my machine. But when I run it on another machine, it becomes very slow.”

When our team investigates, in most cases (not all), this is due to changes in the test environment. (primarily in Window Name). i.e When running on the local box, the test would have been recorded on the Application Window with name ”Application v1.0.1.3”. When the test is run on a different box, the Application Window title has changed subtly. Name has now become “Application v1.0.2.0”.

In this case, the UI Test Framework attempts to find the application window with name “Application v1.0.1.3” and fails in its first attempt. It then waits for a timeout (default 2mins) and attempts again with a Smart match algorithm. Using Smart Match, it will correctly identify the new title “Application v1.0.2.0” and proceed to run the rest of the Coded UI Test successfully. The information that a smart match has been applied is available in the trace logs. (not in the Test Results).


  • How do you confirm that your Coded UI Tests are running slower because of Smart Match timeout?

You will find a warning in the debug trace similar to:

W, 8748, 6, 2011/03/01, 08:28:28.195, 155961250575, QTAgent32.exe, Playback - [WARNING] Internal warning: Window with Class "WindowsForms10.Window" and Title "Application v1.0.1.3" was not found, so similar window with Class "" and Title "Application v1.0.2.0" was accepted.


  • How do you fix the Coded UI Test so that tests complete quicker under such scenarios?

You can modify the Window search to handle the dynamic name. You do this by adding a UIMap constructor in the file UIMap.cs and override the Window name search.


public UIMap()
    this.UIApplicationv1013Window.SearchProperties.Add(WinWindow.PropertyNames.Name, "Application v", PropertyExpressionOperator.Contains);

Here I have modified my Window Name search to just “Application v” and I am ignoring the dynamic version component of the title.