How to automate WPF and WinForms application testing
WPF and WinForms applications can be tested automatically if their controls provide enough stable information. A test does not need to click based on an image or a position on the screen. Before creating a complete suite, however, it is important to verify the specific application, especially custom tables, charts and older components.
Why a large proportion of repeated checks remain manual
Desktop processes tend to be long and depend on the state of the computer, local files or a database. Before release, people therefore go through the same forms repeatedly, but when time is short, they reduce the checklist to the area around the latest change. An error may then appear in a seemingly unrelated part of the application.
The first attempt at automation often uses a click recorder. The suite works on its author’s computer but starts failing at a different resolution or after a layout change. The problem is not the desktop itself, but the way elements are identified and an unprepared test environment.
How Windows UI Automation works
Microsoft UI Automation provides an interface through which a testing tool examines and controls application elements. By default, WPF creates what are known as automation peers for its controls; depending on the type of element, WinForms may use UI Automation or the classic Win32 interface.
A test can therefore find a text field by its type, name and identifier rather than by fixed coordinates. This makes it more resilient to ordinary visual changes, but not to every structural change. Custom components must expose the required properties, and AutomationId needs to be assessed within the correct window or container.
pywinauto in Python or FlaUI in .NET are often suitable for implementation. We discuss their differences and selection criteria in the pywinauto or FlaUI comparison.
From technical assessment to the first suite
A reliable process has four steps:
- Interface inspection. We check which elements the tool can see and what properties they provide.
- Pilot scenario. We choose an important process with both common and more complex elements and verify it from input to outcome.
- Stable environment. We prepare known test data, accounts, files and a way to restore the environment after a run.
- Maintainable architecture. We centralise access to windows and elements in shared components, and the tests wait for the application’s state rather than for a fixed time.
Graphical tests need a Windows session in which the application can actually run. A local computer, virtual machine and CI are all possible, but the runner needs to be prepared according to the application’s permissions, display requirements, parallel execution and dependencies. We then set the frequency according to the suite’s duration and risk.
What to watch out for
UI Automation is not a guarantee for every custom element. If inspection does not reveal a meaningful structure, identifiers or accessibility support may need to be added to the application’s code. Access to the source code is not always a prerequisite for a pilot, but sometimes a small modification is the least expensive route to stable tests.
What you gain
Repeatable scenarios reduce manual checks before release and give the team the same verification after every relevant change. Testers can devote more time to exploratory testing, new features and situations that cannot easily be scripted.
The pilot also shows the actual return before an investment in the complete suite. You know which screens are ready for automation, which technical changes they need and which checks are more sensible to keep manual.
Next step
Choose one critical scenario that the team repeats before every release and inspect its elements with an inspection tool. If the pilot remains stable over several repetitions, expand the suite according to business risk. For a combined product, you can also assess automation of the web component separately.