Skip to main content

Testing Windows Native Apps

Beginning with Cycle 2.4, Cycle now has the ability to interact with native Windows applications by using the WinAppDriver (WAD). These new native app Steps allow Cycle to interact with Windows applications without relying on desktop Steps that are not tied to a specific running application or using image matching.  

WinAppDriver supports testing Universal Windows Platform (UWP), Windows Forms (WinForms), Windows Presentation Foundation (WPF), and Classic Windows (Win32) apps on Windows 10 PCs.

Steps on setting up WinAppDriver and Cycle can be found at the following link:

When to Use Native App Steps​

Using Cycle’s native application Steps is the preferred method when testing Windows applications. The following conditions are good decision points when deciding whether or not to use native app Steps instead of using the traditional desktop Steps and image matching:

  • You are using Windows 10 or Windows Server 2016 OS
  • The application you are testing has useful object locators that allow you to pinpoint specific objects (text boxes, radio buttons, icons, etc…) to interact with on screen
  • You are developing Cycle features that will be run on different machines than the machine you are using for developing

Cycle desktop Steps and image matching Steps will interact with Windows applications, but these Steps have limits that can result in negative test results. These limits should be taken into consideration when deciding whether or not to use native app Steps.

Desktop Step Limitations:​

  • You cannot guarantee the current application in focus on the desktop is the application you are testing. Cycle completes the desktop Steps as written. Any key presses, typing, or clicking will continue to happen on the desktop in whatever application is currently running and the test will fail.
  • You cannot guarantee mouse or cursor position on screen when using a feature that was developed on a different system with a potentially different resolution.

Image Matching Limitations:​

  • Screen resolution, themes, and color settings can vary across multiple devices. Images matching on one machine may not match on another machine if all video settings are not identical. These differences will cause tests to fail.
  • Image matching can lead to false negative and positive results depending on the image correlation setting.
  • Visual changes to the application due to a patch or modification may require images to be recaptured for the feature to execute properly.
  • Developing features to run on multiple machines may require multiple libraries of image files.

Desktop Steps and image matching can be utilized to test Windows applications, but their limitations tend to make them less reliable that terminal Steps and web Steps. The native app Steps are much more in line with the precision provided by web Steps and are the preferred option for interacting with Windows 10/Windows Server 2016 applications.

Using Native App Steps​

Native app Steps are very similar to the existing web Steps. There are four locator types that can be used to identify objects on the screen (id, automationID, name, and controlType). Your ability to identify specific objects within the application will be dependent upon how the application developer assigned these attributes to the objects during development.

You may find that you need to use a combination of locator types to identify specific objects. In these instances, you can use the xPath locator to identify a specific objects using locators and other objects in relation to the specified object. The usage of the xPath locator type is similar to web Steps.

Usage of native app Steps requires a technical approach to feature writing. These Steps are not as simple as image matching where Cycle allows the user to capture images to use for matching.

If you are comfortable developing web features using element locators and xPath, then you will be able to use the native app Steps without much trouble. Less technically inclined users may find using native app Steps as a challenge until they are able to become comfortable with evaluating object locators and determining how to uniquely identify those objects.

Windows Accessibility Insights is a tool that can be used to evaluate and identify application objects during feature writing. This is very similar to using the inspect feature within the Chrome web browser. Accessibility Insights can be downloaded here.

The link below describes how to use Windows Accessibility Insights to identify application objects:

Using Accessibility Insights