Coded UI automation, without Coded UI Test

What actually happened to Coded UI Test

Coded UI Test shipped with Visual Studio 2010 as Microsoft's answer to writing automated UI tests in C# against WPF, WinForms, Win32, and MFC applications. It was built on top of Microsoft UI Automation (UIA), which is the accessibility API Windows still ships today, and it exposed that API through the Microsoft.VisualStudio.TestTools.UITesting namespace. You would drop a UIMap.uitest file into your test project, open the Coded UI Test Builder, point-and-click at controls, and Visual Studio would generate a UIMap.Designer.cs file with a typed class per control.

Microsoft officially deprecated the framework in Visual Studio 2019 and did not bring it forward as a new project template in Visual Studio 2022. The runtime still loads for legacy projects, but the Test Tools installer workload no longer offers Coded UI as a first choice. The Coded UI Test Builder has not received a meaningful update in years. Meanwhile, the underlying accessibility API, UIA, is not going anywhere. The layer Microsoft abandoned is the high-level coded UI automation layer, not the plumbing underneath.

The rest of this guide is what to do about it. The short version is that you keep every AutomationId you ever tagged, you throw away the UIMap files, you replace the runner with something that parses selectors as an expression, and you gain cross-platform support, Playwright-shaped chains, and an MCP server for your coding assistant in the bargain.

Side by side: the Calculator test, then and now

Both of these add 1 + 2 in the Windows Calculator, locate the result display by its AutomationId (which is CalculatorResults, and has been for years), and assert the answer. The left side is the smallest coherent slice of a real Coded UI Test project, generated UIMap class included. The right side is the full contents of examples/win_calculator.py condensed to the same happy path.

// CUIT: UIMap.Designer.cs (auto-generated)
public class CalculatorResultsControl : WinText
{
    public CalculatorResultsControl(UITestControl searchLimitContainer)
        : base(searchLimitContainer)
    {
        this.SearchProperties[UITestControl.PropertyNames
            .AutomationId] = "CalculatorResults";
        this.WindowTitles.Add("Calculator");
    }
}

// CUIT: CodedUITest1.cs
[CodedUITest]
public class CalculatorTest
{
    [TestMethod]
    public void AddOnePlusTwo()
    {
        var ui = new UIMap();
        Mouse.Click(ui.OneButton);
        Mouse.Click(ui.PlusButton);
        Mouse.Click(ui.TwoButton);
        Mouse.Click(ui.EqualsButton);
        Assert.AreEqual("Display is 3",
            ui.CalculatorResultsControl.DisplayText);
    }
}

The AutomationId is the same string in both snippets. That is the whole point. The work you did years ago to make your WPF or WinForms app accessible is the work a modern runner uses to drive it. You are changing the test harness, not the application.

The anchor fact: one file maps every selector to Playwright

The entire selector grammar is documented in one place: docs/SELECTORS_CHEATSHEET.md. It lists fourteen atomic prefixes (role:, name:, id:, nativeid:, classname:, text:, pos:x,y, visible:, rightof:, leftof:, above:, below:, near:, nth:) plus the >> chain combinator, the && compound operator, and the .. parent navigator. The table in that file has an explicit "Rough Playwright equivalent" column for every one of them. A Playwright user reading down that table learns the desktop grammar in about two minutes.

Source: docs/SELECTORS_CHEATSHEET.md in the Terminator repository, the SearchProperties and UIMap patterns in the archived Microsoft.VisualStudio.TestTools.UITesting docs.

How a selector becomes an action

The flow is the same whether you are reading an AutomationId from a Win32 dialog, a WPF button, or a native macOS control. A selector string is parsed into a predicate, the predicate walks the OS accessibility tree, the match resolves to an element handle, the handle invokes an action. No screenshot matching on the hot path. No flakey pixel diff.

The full working example

This is the condensed version of examples/win_calculator.py. Open Calculator, locate five controls by their accessible names, click them in order, read the result display through its AutomationId, assert. It is ten lines of real work and it is the same thing a Coded UI Test project does with a UIMap file, a designer class, and an MSTest attribute.

Install and wire it into your agent

Pick the language your existing tests already live in. The Rust core is the same under all three SDKs. The last command registers the MCP server so an AI coding assistant can drive the same selectors at the tool-call level.

What the deprecation actually cost you, and what you get back

A concrete inventory of what leaves the building when you move off Coded UI Test, and what arrives in its place. Nothing here is aspirational; every row corresponds to code in the Terminator repository.

What it looks like in numbers

Frequently asked questions