Bring your Windows applications back to life.
Charging Forward
Windows automation is complicated. It’s a problem that never really got a comprehensive solution, and the long-running nature of Windows’s development meant that backwards compatibility was an endlessly growing catalog of edge cases.
For the last decade (or two), the solution to this problem was to bypass it; by moving your applications to the web, you can use automation tools like Selenium and Playwright that aren’t marred by the same compatibility challenges that Windows has. These tools have thrived on the web, but their technological advancements never quite made it back to Windows automation.
The closest example is Microsoft’s official test automation tool, WinAppDriver, but it hasn’t had much innovation in the past few years. Although it was intended to be a Selenium-like service, it often gets provided through tools like Appium which cover functional gaps. That means running an Appium server as an extra layer in front of it, just to make it work.
Even then, the WinAppDriver tool itself doesn’t have the modern design capabilities showcased by Playwright, despite also being developed by Microsoft. It seems like the solution from the source is to move from Windows to web.
Looking Backward
Unfortunately, this isn’t how things work in the real world, is it? It’s not a simple task to move an application into web-hosting. You might be locked onto an ancient version of an app for product support. If you’re a tester and your company has an old WinForms application, you’re on your own to implement and automate testing for this tool. You’ll need to pick a driver, code around the limitations of each, and solve all of the little implementation details that Windows requires before you can even start considering the behaviors that need to be tested. Your tests end up being brittle, the company is held back by testing, and you end up with the weight of these edge cases on your shoulders.
In one role, I needed to string together an Appium driver with the Robot framework and a few custom PowerShell scripts to cobble together all of the functionality that I needed. After all of that work, I needed to implement the framework-level concerns of element retrying and finder strategies. It got even harder when finally creating the test! I needed the inspect.exe tool to find automation locators in the element tree, and edge cases there left me completely blocked. It was frustrating beyond words.
I needed a Windows automation tool that offered modern testing patterns, handled Windows’s idiosyncrasies out-of-the-box, and slotted right into my projects with minimal setup requirements.
I wanted to move the progress from Web to Windows.
Charging Backward
AutoMancer is my solution: automated Windows necromancy! A simple C# engine and CLI built around modern testing patterns, with Windows concerns handled for you.
It stands by itself with no other services to install. It’s a class library that can be referenced from a C# project and includes all of the retry logic, locator strategies, and wait handling that you’d usually need to write yourself. It threads the needle of offering solutions to common problems without locking in behaviors so that you have options instead of shortcomings. AutoMancer aims to solve whatever weirdness you come across in the Windows application ecosystem.
A core problem I tackled was the plethora of Windows UI implementations. Under the hood, every locator resolves through a fallback chain of Windows history. Modern UI Automation (UIA3) is considered first, then an older interop layer (UIA2) if that doesn’t find anything, and finally raw Win32 window enumeration as a last resort for the applications that barely expose anything to either. AutoMancer has a CLI command to identify the element tree across each provider. You won’t need to worry about all of the differences between these implementations. You can focus on choosing locators.
Test writing offers modern standards for free. The test adapter’s Expect() API follows the pattern Playwright made standard for web automation. A condition is polled asynchronously until it’s true or the wait window runs out, instead of a single find-then-assert race. Windows apps can have unexpected element updating and rendering patterns. You won’t need to invest time debugging these. You can focus on asserting values.
The CLI surface makes this tool AI-ready. Every command is a small, self-contained, text-in/text-out operation. Since that’s the same shape an LLM tool call already expects, an AI agent can drive a real, live Windows app through the CLI surface. You can snapshot the element tree and try clicking or typing against elements without needing hours of trial-and-error. For agent-driven test generation or RPA-style automation, that’s a Windows automation surface that’s ready to go. You won’t need to kick your way through complicated surfaces. You can focus on automating behaviors.
Looking Forward
AutoMancer is now a publicly available open-source project. I’ve been using Spec-Driven-Development to create it with AI tools, but I’ve been careful about what gets added and what gets deferred. I’ll be writing about that progress and sharing tips here soon. For now, the core engine is finished and the next phase’s extended capabilities are documented and under development.
Please take a look and consider using or contributing to it if you resonate with this article. If you maintain tests for a Windows desktop app, I’d appreciate it if you would clone AutoMancer and point it at your toughest, most complicated application. If it breaks, that’s the most useful bug report I could ask for! If there’s a feature that make your life easier, please say so. If you’ve fought this same fight before, I’d love to hear how.
Again, the project is at github.com/pturch/AutoMancer. Star it if you want to follow along, open an issue if something’s in your way, or send a PR if you’ve already fixed it yourself.
Windows automation has been buried under technical issues for years. With a little “QA magic,” I think we can resurrect it.
Leave a Reply