How UI Automation Helps with Unit Testing and Accessibility
Quick Start Guide | |
---|---|
What You Will Need |
|
Controls Referenced | |
Tutorial Concept | Learn how UI automation can be applied in .NET applications to solve two specific use cases: unit testing and end-user accessibility. Plus, see how UI automation works using the ComponentOne Ribbon for WinForms. |
Microsoft UI Automation is a framework for programmatically accessing UI elements in .NET applications. It serves two primary functions: creating robust automated UI tests and enabling accessibility for users with disabilities. The framework provides a single model for interacting with UI controls, making it a critical technology for modern WinForms and WPF development.
This blog will cover how UI Automation works and its application in the .NET platform. We will walk through a complete use case, including setting up a sample application, configuring a test environment, and writing UI tests. We will also demonstrate how the new UI Automation support in the ComponentOne Ribbon for WinForms control improves screen reader accessibility. We will discuss:
- What Microsoft UI Automation Is
- Automated UI Testing with C1Ribbon
- Improving Accessibility with UI Automation
Ready to Get Started? Download ComponentOne Today!
What is Microsoft UI Automation?
Microsoft UI Automation exposes every element of an application's UI in a hierarchical structure known as the automation tree. Each control, from the main window down to a single button, is represented as an object with a set of properties that can be read and manipulated programmatically. This design directly enables its two main use cases:
- Automated UI Testing: Scripts can simulate user actions and verify the state of UI elements to validate application behavior.
- Accessibility: Assistive technologies like screen readers use the automation tree to understand the UI's layout and controls, describing them verbally to a user.
The C1Ribbon control supports UI Automation by supporting the IAccessible interface. All UI elements within the Ribbon are named so they can be programmatically accessed.
Next, let's examine how these two practical use cases of UI Automation work with a ComponentOne UI control such as C1Ribbon.
Use Case 1: Automated UI Testing with C1Ribbon
Automated UI testing is a standard practice for improving software quality. To demonstrate this, we will first create a simple WinForms application with a ComponentOne Ribbon in WinForms and then write a unit test to verify the state of its buttons.
Setting Up the Test Environment
To test this application, we will use Appium with WinAppDriver. Follow the steps below to configure your environment.
Step 1: Enable Developer Mode on Windows. Navigate to Windows Settings > Update & Security > For Developers and toggle Developer Mode to On.
Step 2: Install Node.js and Appium. Then, open a Command Prompt and run npm install -g appium to install the Appium server.
Step 3: Install and Run WinAppDriver. Download and install the WindowsApplicationDriver.msi from the WinAppDriver GitHub releases page. Before running any tests, you must start WinAppDriver.exe from its installation folder (C:\Program Files (x86)\Windows Application Driver). A console window will appear and must remain running. WinAppDriver will use port 4723 by default.
Creating a Sample WinForms Application
First, create a WinForms project named RibbonUI. In this application, we will add a C1Ribbon control with two buttons: an enabled "Copy" button and a disabled "Paste" button. This setup simulates a common scenario where UI control availability changes based on application state (e.g., the clipboard being empty).
Writing the UI Automation Test
Next, create a Unit Test Project (.NET Framework) project in your solution and add the Appium.WebDriver NuGet package. The following test class will launch the AutomatedTesting application and verify the Enabled state of both ribbon buttons.
Note the Appium and Selenium version requirements depending on the framework of your .NET project. For this project, we will use Appium 4.4.5 and Selenium 3.141.0.
When executed from the Visual Studio Test Explorer, these tests programmatically confirm that the UI state of the C1Ribbon buttons is correct.
The WinAppDriver in the terminal will now also display the results of the test.
We can confirm the output and test passed by verifying the following lines:
- {"using": "name", "value": "Paste"}
- First, we see the request our test script sent to the WinAppDriver server. The
POST
command, along with the JSON payload{"using":"name","value":"Paste"}
, is the direct translation from our Test codesession.FindElementByName("Paste")
. It's asking WinAppDriver to find an element using the 'name' locator strategy with a value of 'Paste'.
- First, we see the request our test script sent to the WinAppDriver server. The
- HTTP/1.1 200 OK:
- Next, we get the confirmation from the server. The status code
HTTP/1.1 200 OK
is the standard success response for web protocols. This tells us that WinAppDriver received the request, understood it, and successfully found the 'Paste' button in our application's UI.
- Next, we get the confirmation from the server. The status code
- {"sessionId": "...", "status" :0, "value" :{ "ELEMENT": "42.3672260.4.2.0.1"}}
"status":0
: In the WebDriver protocol, a status of 0 means the command completed without errors."value":{"ELEMENT":"..."}
: This is the most crucial part. WinAppDriver is returning the element it found. The long string42.3672260.4.2.0.1
is a unique ID that WinAppDriver has assigned to the 'Paste' button. For any future actions in our test, like checking if the button is enabled (pasteButton.Enabled
), our script will now use this specific ID to tell WinAppDriver exactly which element to interact with.
Use Case 2: Improving Accessibility with UI Automation
The UI Automation properties our tests just used are the same properties that assistive technologies rely on. The test Assert.False(pasteButton.Enabled)
is the developer's way of proving that a screen reader will receive the correct information.
With proper UI Automation support, a screen reader can provide a descriptive and functional user experience.
- Without proper support, a screen reader's output for the ribbon is generic:
"Button... Button... Pane..."
- With the new C1Ribbon support, the output is precise and navigable:
"Home Tab. On ribbon, Clipboard group. Copy button. Paste button, unavailable."
This clear output, especially announcing "unavailable" for the disabled button, is critical for a non-visual user to understand the application's state without confusion.
We can visually confirm this using Microsoft's built-in Inspect program to verify. We can see that we are hovering over the 'Paste' button and that it is disabled.
To get and work with Windows Inspect.exe, you must install the Windows SDK.
- Download the Windows SDK: You can download the official installer from the Microsoft website:
- Locate the File After Installation: Once the SDK is installed, you can find
Inspect.exe
in a subfolder of the Windows Kits directory. The exact path can vary depending on the SDK version and your system architecture (x86 or x64), but it typically follows this pattern:
C:\Program Files (x86)\Windows Kits\10\bin\<SDK_VERSION>\<PLATFORM>\Inspect.exe
For example: C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\Inspect.exe
Ready to check it out? Download ComponentOne Today!
Conclusion
Microsoft UI Automation is essential for creating high-quality, accessible .NET desktop applications. As demonstrated, a single implementation provides the foundation for both automated testing and accessibility. The unit tests we wrote programmatically verified the same control properties that a screen reader uses to inform the end-user.
The enhanced UI Automation support in the ComponentOne Ribbon for WinForms provides the necessary infrastructure to build applications that are both more reliable through testing and more inclusive for all users.