WinAppDriver Alternatives for Apps With No Accessibility Tree

When the test tool cannot see your app

You point Inspect at your application's Save button, and it shows one blank pane.Your locator finds nothing, the WinAppDriver test fails, and the search for a WinAppDriver alternative begins.

This guide explains how Windows desktop test automation works, which applications it cannot see, and how to test such a Windows desktop application anyway: by finding every element by sight, the way a person does.

How does Windows desktop test automation work?

Each application describes its interface to Windows as a tree.The window holds panes, and the panes hold buttons, fields and lists, each with a name, a type and a place on the screen.Microsoft Active Accessibility, or MSAA, is the older technology that does the same for older programs.

A test tool reads that tree, finds an element with a locator such as its AutomationId, its name or an XPath through the tree, then clicks it, types into it or reads its value.

This works well when the tree is complete.Microsoft ships the description of every standard Win32, Windows Forms (WinForms) and WPF control, so those appear in the tree by themselves.A custom control is different: its developers must write that description, and without it, Microsoft's documentation says the control is largely opaque to UI Automation, which can report little more than its location.

WinAppDriver and its alternatives read the same tree

WinAppDriver, Microsoft's Windows Application Driver, brought Selenium-like automation to UWP, Windows Forms, WPF and classic Win32 apps.Its last stable release on GitHub, version 1.2.1, dates from November 2020, followed by a 1.3 release candidate in July 2021.The Appium Windows driver built on top of it is now marked deprecated, and its documentation names the Appium WinCore driver as the official replacement.

The usual alternatives each take a different road to the same tree:

Even Microsoft's newest guidance for WinUI 3 apps, the winapp ui commands for AI agents, reads the live accessibility tree and asks developers to set an AutomationId on every interactive control.

For the web testing tools side by side, see the comparison study.

Which Windows apps have no accessibility tree?

Point Inspect at any of these, and you will often find one blank pane where you expected a form.This is the daily reality of legacy application testing, and of many modern apps too.

Sometimes the tree exists, but you may not touch the application: a program from another vendor, a build locked down for an audit, a team that cannot add AutomationIds for you.Any tool that needs a test build, an agent inside the app or a change to its code is then out of reach.

How to check your own app in two minutes

1. 1

   Open an inspection tool

   Install Accessibility Insights for Windows, Microsoft's inspection tool, or use Inspect from the Windows SDK.

2. 2

   Hover over the elements your tests need

   Each one should appear with a name, a type and an AutomationId.

3. 3

   Read what you see

   One pane for the whole window, or elements with no name, means a tree-based tool cannot find them reliably.

Image-based testing: test what is on the screen

SikuliX is the classic open-source example: you capture a picture of each element and write each step as a line of script.Commercial tools offer it as a fallback.TestComplete's documentation, for instance, says its image-based tests can be recorded only on Android apps: on a desktop app, you capture the images and add the test commands by hand.

Done naively, a test by sight has well-known weak spots.Each one has an answer:

A WinAppDriver alternative that needs no tree

GUI Test Studio is an end-to-end GUI testing suite for Windows that tests any application you can see on your screen, without code.It does not choose between the tree and the screen.

How GUI Test Studio finds elements explains how the two ways work together.Here is what it means for an app with no tree, step by step.

1. 1

   Record the app

   In GUI Test Runner-Recorder, click Record and pick An app.Choose the program among the open apps, or browse to one that is not running yet.Tick the box that starts it with the test and closes it at the end, so every run starts from a fresh app.Then use the app as you always do.

   

   Enlarge

   Choosing an app keeps a notification from another program out of your test, while every click and key you make is still recorded.See Record a test.

2. 2

   Every element is kept two ways

   Each click gets a Visual Assert just before it: a picture of the element, its visual target.When the application describes that element to Windows, the test keeps that description too.When the app answers with one blank pane, there is nothing worth keeping, and the picture alone finds the element.

   Some programs draw their forms by hand and only describe the form's own window.The test keeps that window, so a form that moved is found again where it now stands.

3. 3

   Check what is shown

   A Visual Assert checks that an element is on the screen and looks right.A Text Assert asks the application what an element says, and reads the words on the screen when the application cannot tell.A Dynamic Text Assert checks a value that changes on every run, such as a date or an order number, by its shape.

   Each comparison ignores the small rendering differences every screen has and still catches the real regressions a person would call a change: a wrong color, a missing icon, a word that changed.See Visual checks.

4. 4

   Run it, wherever the window opens

   The test replays your clicks and keys as real mouse and keyboard input, aimed at where each element is now.When a check has not found its element in its Search Scope after a second, it looks over the whole screen too, so a window that moved does not fail the test.The Confidence Report then says the element was found outside its Search Scope, and offers to widen it in GUI Test Studio.

   On a computer with several monitors, a test uses one screen or all of them, and remembers which.

   

   Enlarge

Citrix, Remote Desktop and virtual machines

A Citrix, Remote Desktop (RDP) or VMware Horizon session reaches your computer as one window of pixels.Some tools can reach its controls only when they are installed on the remote server itself, as SmartBear describes for TestComplete.GUI Test Studio tests the session from the computer that shows it, by sight, like any other window.

Pick An app and the session's window when you record, or An area of the screen for one panel of it.An app in a virtual machine works the same way: give the virtual machine a fixed window size, the same on every computer that runs the tests.See What you can test.

Run desktop tests on every build

gtr-cli, the command-line runner, runs a test exactly like the Run Test button.It adds what a pipeline needs: an exit code, a JUnit file, and every piece of evidence of a failure in one folder.

gtr-cli run tests --countdown 0 --junit results\junit.xml --artifacts results\artifacts

A desktop test replays on a real screen, so the build agent needs an unlocked Windows desktop session.A virtual machine with a fixed screen size works well as a test agent.The CI/CD guide sets it up step by step.

Questions

WinAppDriver, Windows, Visual Studio, Selenium, Appium, FlaUI, pywinauto, TestComplete, Ranorex, SikuliX, Delphi, Java, Citrix, VMware Horizon and Electron are trademarks of their respective owners.