If you’ve been working in the .NET ecosystem for a while, you know that WPF (Windows Presentation Foundation) is far from dead. It powers a massive amount of enterprise desktop software. But let’s be honest: testing desktop UI has historically been… painful.

Microsoft’s CodedUI is long gone, and WinAppDriver has had a rocky road. Enter FlaUI.

In this post, we’re going to look at how to set up a robust testing framework for WPF using FlaUI, why AutomationProperties are your best friend, and how we can leverage AI tools like GitHub Copilot to make writing these tests significantly faster.

Why FlaUI?

#

FlaUI is a .NET library that helps with automated UI testing of Windows applications (WPF, WinForms, etc.). It wraps Microsoft’s UI Automation libraries (UIA2 and UIA3) in a clean, fluent API.

Unlike some older tools that relied on coordinate clicks or fragile image recognition, FlaUI interacts with the visual tree of your application, making your tests much more resilient to resolution changes and theming.

The Golden Rule: AutomationProperties

#

Before we write a single line of C#, we need to talk about XAML.

The most common cause of “flaky” UI tests is relying on text labels or dynamic content to find elements. If you find a button by its text “Save”, and someone changes it to “Submit”, your test fails.

The solution is AutomationProperties.AutomationId.

By assigning a stable, unique ID to your interactive elements, you decouple your tests from the visual presentation.

1
2
3
4
5
6
7

<!-- Don't do this if you can help it -->
<Button Content="Save Changes" Command="{Binding SaveCommand}" />

<!-- Do this! -->
<Button AutomationProperties.AutomationId="BtnSaveChanges" 
        Content="Save Changes" 
        Command="{Binding SaveCommand}" />

This ID is invisible to the user but clearly visible to FlaUI.

Setting Up Your Test Project

#

Let’s get practical. You’ll want a separate test project (e.g., NUnit or xUnit).

1. Create a new NUnit Test Project.
2. Install the following NuGet packages:
   • FlaUI.Core
   • FlaUI.UIA3 (UIA3 is generally recommended for WPF)

Here is a basic skeleton of a test that launches an app and clicks a button:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

using FlaUI.Core;
using FlaUI.UIA3;
using NUnit.Framework;

[TestFixture]
public class LoginTests
{
    [Test]
    public void CanClickLoginButton()
    {
        // 1. Launch the application
        var appPath = @"C:\Path\To\YourApp.exe";
        using var app = Application.Launch(appPath);
        
        // 2. Initialize the automation engine
        using var automation = new UIA3Automation();
        
        // 3. Get the main window
        var window = app.GetMainWindow(automation);
        
        // 4. Find element by ID (The robust way!)
        // Tip: In real scenarios, UI takes time to load. Use Retry.WhileNull() to wait for elements.
        var btn = window.FindFirstDescendant(cf => cf.ByAutomationId("BtnLogin"))?.AsButton();
        
        Assert.IsNotNull(btn, "Could not find login button");
        
        // 5. Interact
        btn.Invoke();
    }
}

Supercharging with AI

#

Writing UI tests can be tedious. You have to look up IDs, map them to objects, and write boilerplate code. This is where AI tools like GitHub Copilot shine.

1. Generating Automation IDs

#

If you have a complex XAML view without IDs, you can paste the XAML into your chat with Copilot and ask:

“Add AutomationProperties.AutomationId to all interactive controls in this XAML using a consistent naming convention.”

It will return your XAML with BtnSubmit, TxtUsername, LstItems etc., saving you the manual typing.

2. Scaffolding Page Objects

#

The Page Object Pattern is a best practice where you create a class that represents a specific screen (e.g., LoginPage). This class handles finding elements, keeping your tests clean.

You can provide your XAML to the AI and ask:

“Create a FlaUI Page Object class for this XAML view. Expose the interactive elements as properties.”

The AI can generate something like this in seconds:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

using FlaUI.Core;
using FlaUI.Core.AutomationElements;

public class LoginPage : Window
{
    public LoginPage(FrameworkAutomationElementBase element) : base(element) { }

    public TextBox UsernameBox => FindFirstDescendant(cf => cf.ByAutomationId("TxtUsername"))?.AsTextBox();
    public TextBox PasswordBox => FindFirstDescendant(cf => cf.ByAutomationId("TxtPassword"))?.AsTextBox();
    public Button LoginButton => FindFirstDescendant(cf => cf.ByAutomationId("BtnLogin"))?.AsButton();

    public void Login(string user, string pass)
    {
        UsernameBox.Text = user;
        PasswordBox.Text = pass;
        LoginButton.Invoke();
    }
}

3. Writing the Test Logic

#

Once you have your Page Objects, you can ask the AI to write the actual test scenarios:

“Write an NUnit test using the LoginPage object that verifies an error message appears when the password is empty.”

Summary

#

Testing WPF applications doesn’t have to be a nightmare of fragile scripts. By combining FlaUI for robust automation, AutomationProperties for stability, and AI to handle the boilerplate, you can build a high-quality test suite that actually saves you time. Your future self (and your team) will thank you when that critical refactor doesn’t break the entire application.

Further Reading

#

• FlaUI on GitHub - Official FlaUI repository
• UI Automation Overview - Microsoft’s UI Automation documentation
• AutomationProperties in WPF - API reference
• Page Object Pattern - Martin Fowler’s explanation