Select Page
Desktop Automation Testing

WinAppDriver for Desktop Automation Testing Guide

Learn WinAppDriver for Desktop Automation Testing with setup, C# examples, locators, popup handling, and Windows UI automation.

Mohammed Yasin

Team Lead

Posted on

13/03/2026

SUMMARIZE WITH :

Winappdriver For Desktop Automation Testing Guide

Desktop Automation Testing continues to play a critical role in modern software quality, especially for organizations that rely heavily on Windows-based applications. While web and mobile automation dominate most conversations, desktop applications still power essential workflows across industries such as banking, healthcare, manufacturing, and enterprise operations. As a result, ensuring their reliability is not optional; it is a necessity. However, testing desktop applications manually is time-consuming, repetitive, and often prone to human error. This is exactly where WinAppDriver steps in.

WinAppDriver, also known as Windows Application Driver, is Microsoft’s automation tool designed specifically for Windows desktop applications. More importantly, it follows the WebDriver protocol, which means teams already familiar with Selenium or Appium can quickly adapt without learning an entirely new approach. In other words, WinAppDriver bridges the gap between traditional desktop testing and modern automation practices.

In this guide, you will learn how to set up WinAppDriver, create sessions, locate elements, handle popups, perform UI actions, and build real automation tests using C#. Whether you are just getting started or looking to strengthen your desktop automation strategy, this guide will walk you through everything step by step.

What Is WinAppDriver?

At its core, WinAppDriver is a UI automation service for Windows applications. It allows testers and developers to simulate real user interactions such as clicking buttons, entering text, navigating windows, and handling dialogs.

What makes it particularly useful is its ability to automate multiple types of Windows applications, including:

  • Win32 applications
  • WPF (Windows Presentation Foundation) applications
  • UWP (Universal Windows Platform) applications

Because of this wide support, WinAppDriver fits naturally into enterprise environments where different technologies coexist.

Even better, it follows the same automation philosophy used in Selenium. So instead of reinventing the wheel, you can reuse familiar concepts like:

  • Driver sessions
  • Element locators
  • Actions (click, type, select)
  • Assertions

This familiarity significantly reduces the learning curve and speeds up adoption.

Why Use WinAppDriver for Desktop Automation Testing?

Before diving into implementation, it is important to understand why WinAppDriver is worth using.

First, it provides a standardized way to automate desktop UI interactions. Without it, teams often rely on manual testing or fragmented tools that are hard to maintain.

Second, it supports multiple programming languages such as:

  • C#
  • Java
  • Python
  • JavaScript
  • Ruby

This flexibility allows teams to integrate WinAppDriver into their existing tech stack without disruption.

Additionally, WinAppDriver works well for real-world scenarios. Desktop applications often include:

  • Multiple windows
  • Popups and dialogs
  • Keyboard-driven workflows
  • System-level interactions

WinAppDriver is built to handle these complexities effectively.

Installing WinAppDriver

Getting started with WinAppDriver is straightforward. First, download the installer:

WindowsApplicationDriver.msi

Once downloaded, follow the standard installation process:

  • Double-click the installer
  • Follow the setup wizard
  • Accept the license agreement
  • Complete installation

By default, WinAppDriver is installed at:

C:\Program Files (x86)\Windows Application Driver

Before running any tests, make sure to enable Developer Mode in Windows settings. This step is essential and often overlooked.

Launching WinAppDriver

After installation, the next step is to start the WinAppDriver server.

You can launch it manually:

  • Search for Windows Application Driver in the Start menu
  • Right-click and select Run as Administrator

Alternatively, you can start it programmatically, which is useful for automation frameworks:

ProcessStartInfo startApp = new ProcessStartInfo();

startApp.FileName = @"C:\Program Files (x86)\Windows Application Driver\WinAppDriver.exe";

Process.Start(startApp);

Using a code-based startup ensures consistency and removes manual dependency during test execution.

Creating an Application Session

Once the server is running, you need to create a session to interact with your application.

Here’s a basic example:

AppiumOptions options = new AppiumOptions();

options.AddAdditionalCapability("app", @"C:\notepad.exe");

options.AddAdditionalCapability("deviceName", "WindowsPC");

WindowsDriver<WindowsElement> driver =
new WindowsDriver<WindowsElement>(
new Uri("http://127.0.0.1:4723"), options);

This step is critical because it establishes the connection between your test and the application. Without a valid session, no automation can take place.

Working with Windows and Application State

Desktop applications often involve multiple windows. Therefore, handling window state becomes essential.

For example, you can retrieve the current window title:

string windowTitle = driver.Title;

Console.WriteLine(windowTitle);

This simple check helps confirm that the correct window is active before performing further actions.

Handling Popup Windows

Popups are one of the most common causes of test failures in desktop automation. Therefore, handling them correctly is crucial.

Here’s a typical approach:

var popup = driver.FindElementByName("Popup Title");

popup.Click();

driver.SwitchTo().Window(driver.WindowHandles.Last());

In this flow:

  • The popup is identified
  • An action is performed
  • The driver switches to the latest window

This ensures your test continues in the correct context.

Element Locator Strategies

Choosing the right locator strategy directly impacts test stability.

AccessibilityId (Recommended)

WindowsElement element = driver.FindElementByAccessibilityId("AutomationId");

This is the most stable and preferred option.

Name Locator

driver.FindElementByName("Open");

Useful for visible labels.

ClassName Locator

driver.FindElementByClassName("Button");

Helpful for identifying control types.

XPath Locator

driver.FindElementByXPath("//Window/Button[1]");

Flexible, but should be used cautiously as it is more fragile.

Performing UI Actions

Once elements are located, you can interact with them.

To enter text:

element.SendKeys("Sample Text");

To clear text:

element.Clear();

To click:

element.Click();

To read values:

string value = element.GetAttribute("value");

These actions form the foundation of most automation workflows.

Mouse Actions

Some interactions require more than simple clicks.

For double-click:

Actions actions = new Actions(driver);

actions.DoubleClick(element).Perform();

For right-click:

actions.ContextClick(element).Perform();

These are especially useful for context menus and file operations.

Keyboard Commands

SendKeys.SendWait("{F5}");
SendKeys.SendWait("{ENTER}");
SendKeys.SendWait("^s");
SendKeys.SendWait("{ESC}");

Using keyboard actions makes your tests more realistic and closer to actual user behavior.

Creating a Desktop Root Session

Sometimes, you need to interact with the entire desktop instead of a single app.

Here’s how you create a root session:

var options = new AppiumOptions();

options.AddAdditionalCapability("app", "Root");

options.AddAdditionalCapability("deviceName", "WindowsPC");

var session = new WindowsDriver<WindowsElement>(
new Uri("http://127.0.0.1:4723"), options);

This approach is particularly useful for:

  • File dialogs
  • System popups
  • External windows

Required NuGet Packages

  • Appium.WebDriver
  • NUnit
  • NUnit3TestAdapter
  • Microsoft.NET.Test.Sdk

Complete NUnit Test Example

using NUnit.Framework;
using OpenQA.Selenium.Appium;
using OpenQA.Selenium.Appium.Windows;
using System;

namespace WinAppDriverDemo
{
  [TestFixture]
  public class NotepadTest
  {
      private WindowsDriver<WindowsElement> driver;

      [SetUp]
      public void Setup()
      {
          AppiumOptions options = new AppiumOptions();

          options.AddAdditionalCapability("app", @"C:\Windows\System32\notepad.exe");
          options.AddAdditionalCapability("deviceName", "WindowsPC");

          driver = new WindowsDriver<WindowsElement>(
              new Uri("http://127.0.0.1:4723"),
              options);

          driver.Manage().Timeouts().ImplicitWait = TimeSpan.FromSeconds(5);
      }

      [Test]
      public void EnterTextInNotepad()
      {
          WindowsElement textArea = driver.FindElementByClassName("Edit");

          textArea.SendKeys("Hello WinAppDriver Automation");

          string title = driver.Title;
          Assert.IsTrue(title.Contains("Notepad"));
      }

      [TearDown]
      public void TearDown()
      {
          driver.Quit();
      }
  }
}

Best Practices for Stable Desktop Automation

  • Prefer AccessibilityId over XPath
  • Always wait for elements to be visible
  • Handle popups using proper window switching
  • Use Root sessions for system-level interactions

In practice:

  • A stable locator is better than a clever locator
  • A ready element is better than a rushed interaction
  • A dedicated session is better than forcing one session to handle everything

These small decisions significantly reduce flaky tests and improve long-term maintainability.

Conclusion

WinAppDriver provides a powerful yet approachable way to implement Desktop Automation Testing for Windows applications. It combines the familiarity of WebDriver with the flexibility needed for real desktop environments. By following the right setup, using stable locators, handling popups correctly, and structuring tests properly, teams can build reliable automation frameworks that scale over time. Ultimately, success with WinAppDriver is not just about tools it is about building a strategy that prioritizes stability, clarity, and maintainability.

Want to build a reliable WinAppDriver framework for your team? Get expert guidance tailored to your use case.

Talk to an Automation Expert

Frequently Asked Questions

  • What is WinAppDriver used for?

    WinAppDriver is used for Desktop Automation Testing of Windows applications. It allows testers to automate UI interactions such as clicking buttons, entering text, and handling windows in Win32, WPF, and UWP apps.

  • How does WinAppDriver work?

    WinAppDriver works using the WebDriver protocol, similar to Selenium. It creates a session between the test script and the Windows application, allowing automation of user actions like clicks, typing, and navigation.

  • Which applications can be automated using WinAppDriver?

    WinAppDriver supports automation for multiple Windows application types, including:

    Win32 applications

    WPF (Windows Presentation Foundation) apps

    UWP (Universal Windows Platform) apps

    This makes it suitable for both legacy and modern desktop applications.

  • What is the best locator strategy in WinAppDriver?

    The most reliable locator strategy in WinAppDriver is AccessibilityId. It provides stable and maintainable element identification. XPath can also be used, but it is less stable and should be avoided when possible.

  • Can WinAppDriver handle popup windows and dialogs?

    Yes, WinAppDriver can handle popup windows by switching between window handles. For system-level dialogs, a Desktop Root Session can be used to interact with elements outside the main application.

  • Is WinAppDriver similar to Selenium?

    Yes, WinAppDriver is similar to Selenium because both use the WebDriver protocol. The main difference is that Selenium automates web browsers, while WinAppDriver automates Windows desktop applications.

Comments(0)

Submit a Comment

Your email address will not be published. Required fields are marked *

Top Picks For you

Talk to our Experts

Amazing clients who
trust us


poloatto
ABB
polaris
ooredo
stryker
mobility