Testing desktop applications

Why desktop tests should not rely on coordinates and images

Recording clicks is a quick way to create a first automated scenario. If the test remembers only a cursor position or an image of a button, however, it responds to the appearance of the screen rather than the meaning of the element. A long-term regression suite therefore needs a more stable foundation.

Why tests start failing without an application defect

A test that clicks point 412 × 260 does not know whether the Save button is at that position. Moving the window, using a different resolution, changing Windows scaling or adding a new row to the form may cause it to click beside the button. Sometimes the test fails; at other times, it performs the wrong action and produces a misleading result.

Image-based matching is slightly more flexible, but it still depends on the font, colour, theme, resolution and rendering quality. The problem is particularly apparent when tests run on a different computer from the author’s or when the application receives a visual change without a functional change.

This does not mean that visual comparison is wrong. It is appropriate when appearance is the subject of the check—for a chart, document preview or print layout, for example. As the main way to control forms, however, it usually creates an unnecessary amount of maintenance.

How a more stable approach works

Windows UI Automation provides a structured tree of application elements. A test can distinguish a window, text field, table and button and work with their properties. Instead of a position, it can look for a button with a particular identifier in a specified window.

When designing locators, we proceed from the most stable information:

1. a unique AutomationId in the correct window or container;
2. the element type combined with a stable name or another property;
3. the relationship to a parent element if the identifier alone is insufficient;
4. order or coordinates only as a last, deliberately accepted option.

An AutomationId does not have to be unique across the entire application, so the search scope also matters. We centralise access to screens in shared test-suite components so that changing one element does not require dozens of scenarios to be modified. The test also waits for a particular application state rather than a fixed number of seconds.

The limits of UI Automation

Not every custom graphical element provides the system with sufficient information. The application therefore needs to be examined with an inspection tool before work begins. Sometimes adding names, roles or identifiers to the application code helps; in other cases, a combined approach is required.

A change of colour or position will then generally not affect the test, although a change to an element’s name or structure may. UI Automation does not remove maintenance; it ties maintenance to meaningful interface changes. Good exposure of elements can also help assistive technologies, but it does not replace accessibility testing on its own.

What you gain

Tests will be less sensitive to resolution, theme and minor visual changes. When a scenario fails, it is more likely to be flagging a change in application behaviour or structure rather than a shifted pixel.

The team also gains more predictable maintenance. Stable locators and shared screen objects shorten repairs after a redesign and make it easier to distinguish an application defect from a test defect.

Next step

On one important screen, compare what the user sees with what appears in the Windows UI Automation tree. If you find stable names, types and identifiers there, rewrite one frequently failing scenario and monitor its results across repeated runs. For WPF and WinForms, continue with how to assess the application’s technical suitability.