Quality AssuranceOctober 12, 2022

Combining Web and Desktop Testing in a Single Test Case Using TestRay

Evelīna Abramova

Two QA engineers performing web and desktop testing using TestRay

Have you ever wondered whether it is possible to combine web and desktop testing in a single test case in one project? Well, the short answer is yes—with the right test automation tools. However, in order to get to this stage, you need to know more about testing web and desktop apps. Specifically, what makes them so different, yet so alike? Or what are some automation testing tools and how can we configure roles for web and desktop apps? And, of course, how can we combine web and desktop testing in a single test case? Let’s find out the answers to these questions and more.

Differences between web and desktop application testing

Desktop applications are platform-dependent. This means that they are programmed to be deployed on specific platforms and can only be used by one user at a time. As a result, each test script for each platform needs to be developed independently. This also means that desktop applications should be approached differently, as performance, accessibility, and the UI can differ, depending on the platform that the app is tested on. Desktop environments also vary depending on the hardware you are using, so it can majorly affect how the application is behaving.

On the other hand, web applications can be accessed from any computer with a web browser, as they only need an internet connection to access the server where the application is stored. Automating a web app does not require writing test scripts for different platforms as is the case with desktop applications. Although web applications are designed with high accessibility, they rely heavily on the internet and distributed components of the systems that interact with the application, which make them more complex.

Another difference between testing web and desktop apps can be seen when maintaining test scripts. Namely, when a web application receives an update it is applied immediately, while in the case of a desktop application, the update is usually applied with manual user intervention. So it is crucial to monitor tests, as it is not enough to only write them, but you should also keep in mind that an update can potentially affect the app flow and UI.

Automation testing tools for web and desktop apps

There are quite a few prerequisites you should take care of to be able to execute automated test scripts. These things may vary depending on what framework or language you are using for automation. At TestDevLab, we use a custom framework, TestRay, whose base prerequisites are Appium, Java, Node.js and Ruby. If you haven’t heard about TestRay, we suggest you read our blog post, which describes it in more detail, or visit TestRay’s GitHub repository.

Additionally, to be able to automate Windows applications, Windows Application Driver (WinAppDriver) should be installed. Appium is used to automate Windows desktop apps and it relies on WinAppDriver, which makes it possible to automate desktop apps in the first place.

When writing test scripts for desktop applications, you should find the solution that would satisfy the needs of testing and support the inspection of UI elements. Depending on the platform and application under test, it is vital to choose a tool that shows different element properties, such as name, ID, and so on.

For Windows desktop app automation in particular, you can use the Microsoft Accessibility Insights tool to find the elements of an app (there are other automated testing tools for Windows desktop apps, of course, so you can choose the most suitable one for you, like WinAppDriverUIRecorder, which goes together with WinAppDriver. The Inspect mode of this Accessibility Insights tool, for instance, allows the tester to view the text/name associated with the UI element, which is then used to create the XPath locator of the element (CSS locators do not work in desktop apps).

For macOS, in order to create a test case for desktop apps, AppiumForMac (AXPath syntax) is the handbook for finding the right selectors and being able to control the UI of applications on Mac. And it’s quite easy to use. Place the pointer over the element you need, hold the “Fn” key for the selector to be copied to the clipboard, and just paste it in your code. A newer alternative for this tool is Mac2Driver, which uses XCUI element syntax.

For web applications, if Google Chrome is used, then you can use Chrome DevTools (which are built into the browser) to inspect elements of the webpage and choose the right selectors for the test scripts, either CSS or XPath. Note that in order to launch the tests, a matching version of the ChromeDriver tool should also be installed.

Configuring roles for web and desktop apps using TestRay

When starting to write a test script, a good practice would be to begin with the configuration file, where you will be defining apps, devices and roles which will be in use for automated tests. TestRay makes automation of desktop applications much more easier and human-readable. When applications and roles that you will use in your test are defined, you can use and reuse them. The first thing you would have to do in your new configuration file is to specify an application of your choice and a path to it so that the WebDriver can identify it. Here is an example:

Apps:  
  Chrome:
     Package: com.android.chrome
  YourApplication:
     WinPath: <path to YourApplication>
#or
     UWPAppName: <YourApplication ID for Universal Windows Private App>
#or
     App: <YourApplication ID>

After you have defined the application you want to test and where to find it (path to the .exe file or app ID), you should specify the device that will be doing the operations. Different variations of this can be seen below as well as an explanation of the purpose for each of them.

Devices:  
  - role: command1
  - role: localMac
    platform: Mac
  - role: localWindows
    platform: Windows
  - role: desktopChrome
    capabilities:
     chromeOptions:
       prefs:
         profile.default_content_setting_values.notifications: 1
         profile.default_content_setting_values.media_stream_mic: 1
         profile.default_content_setting_values.media_stream_camera: 1
         hardware.audio_capture_enabled: True
         hardware.video_capture_enabled: True
         hardware.audio_capture_allowed_urls: ["https://<YourApplicationWebPage>"]
         hardware.video_capture_allowed_urls: ["https://<YourApplicationWebPage>"]
       args:
         - use-fake-ui-for-media-stream
         - use-fake-device-for-media-stream
         - no-sandbox
         - disable-gpu
         - use-file-for-fake-video-capture= <Path to the video to use as fake web camera>
         - use-file-for-fake-audio-capture= <Path to the audio to use>
         - headless
   browser: chrome

In this example we can see that the command role is used for command-line operations, but localMac and localWindows for local machine operations with desktop applications for macOS and Windows, respectively. The role desktopChrome would be used for web application tests, where we add additional capabilities for our testing purposes. Prefs are preferences with a value applied to the user in use, for example, disabling or accepting browser push notifications. Args, or command-line arguments, are specifications which are taken into account when starting Chrome. For example, using flags like a headless browser makes automation much faster and improves performance because there won't be a user interface. Similarly, use-fake-ui-for-media-stream lets you avoid the need to grant camera or microphone access, while use-fake-device-for-media-stream lets you use a fake device instead of a live camera. You can add or remove args based on the needs of your testing activities.

Combining web and desktop apps testing in a single test case

There may be a situation when there is a need to automate a case that involves both a web and a desktop app. This could be, for instance, a video call that has more than two participants. If you have two participants in the video call, with two different devices playing the roles of the sender (the one who is streaming the video and audio) and the receiver (the one who receives the incoming video and audio), the steps for automating an app for desktop tests are obvious—install the app on both devices and for the test script, find the element IDs with the tool of your choice, for example, either with the Accessibility Insights (Windows) or AppiumForMac (macOS) tool.

However, when we automate group calls with more than two participants involved (for instance, 8 or even 50), another solution should be found, as it would be counterproductive to build an automation setup with this amount of physical devices under test. Therefore, it comes in handy to combine web and desktop app test development for all of those extra users that we need just for the sake of their presence in a group call.

Two devices playing the role of sender and receiver in a video call

Using web automation knowledge and the browser dev tools for choosing the right element selector, we can implement separate steps in our test script for the extra users to join the call through the web application. TestRay action types allow us to navigate to the web pages and send our desired text (for instance, login info) in a simple and human-readable manner.

Below you can see a basic example of how the test for a desktop/web video conferencing application with TestRay could look like. Defining participant usernames or roles as variables and retrieving them using the $AND_CLI$ syntax allows you to reuse the same steps for as many participants as you need.

# main test case, which combine all supporting cases and will be executed
DesktopAppMeeting:
 ParallelRoles: true
 Vars:
   USER_1: Antonio
   USER_2: Roberto
   USER_3: Francisko
   CREATOR: localWindows
 Roles:
   - Role: $AND_CLI_CREATOR$
     App: YourApplication
   - Role: desktopChrome
     App: desktop
   - Role: command1
     App: command
 Actions:
# here goes steps for automated actions
    - Given: I open the desktop app and start the meeting
      Vars:
        USERNAME: $AND_CLI_USER_1$
    - And: I navigate and join the meeting from a chrome browser
      Vars:
        USERNAME: $AND_CLI_USER_2$

StartTheConferenceCall:
# supporting test case, which executes actions on a desktop application
  ParallelRoles: true
  Step: I open the desktop app and start the meeting
  Vars:
    CREATOR: localWindows
  Roles:
   - Role: $AND_CLI_CREATOR$
     App: YourApplication
  Actions:
# here goes steps for automated actions
    - Type: click
      Role: $AND_CLI_CREATOR$
      Strategy: xpath
      Id: "//*[contains(@Name, \“Username\”)]"
    - Type: send_keys
      Role: $AND_CLI_CREATOR$
      Strategy: xpath
      Id: "//*[contains(@Name, \“Username\”)]"
      Value: $AND_CLI_USERNAME$

JoinTheConferenceCall:
# supporting test case, which executes actions on a web application
  ParallelRoles: true
  Step: I navigate and join the meeting from a chrome browser
  Roles:
    - Role: desktopChrome
      App: desktop
  Actions:
# here goes steps for automated actions
    - Type: navigate
      Value: https://link-to-the-web-app.com/video-conference
    - Type: click
      Strategy: css
      Id: "#userName"
    - Type: send_keys
      Strategy: css
      Id: "#userName"
      Value: $AND_CLI_USERNAME$

These principles apply to applications that are available for both web and desktop. The first step is to create a case for the receiver to create a call from the desktop app using the respective desktop tools for that. Then create a case for extra users to join through the web app by logging in and using the meeting ID or meeting name. This means that you have to possess unique profiles for each user and define roles for those in the config file. Finally, create a case for the sender to join the new meeting through the desktop app, so that all participants meet in the same virtual room—two through the desktop app and the rest through the web app—with the help of Selenium Grid, headless Chrome sessions, and the execution of TestRay parallel instances.

Selenium Grid helps to handle multiple sessions in parallel and allows the execution of WebDriver scripts. The code does not even need to be present on the system they execute. The result of using Selenium Grid is that web cases are triggered on the local machine, but are executed on the remote one. Of course, you would first need to configure the remote server in order for that to work. But the main advantage is that it allows you to run multiple test cases simultaneously, and as a result, it saves time when running test suites. The grid works on the hub-node concept, which basically means that the test is run by one machine (hub), but the execution is done by multiple machines (nodes). Nodes are registered with the hub. The hub knows which browsers or spots are available and sends requests to the nodes for execution. So when handling extra users with Selenium Grid, you have to make sure that your concurrency allows you to create all of those sessions you have in mind.

Selenium Grid, by default, uses port 4444 for its web interface. In order to reach it on the remote machine, you would have to specify the IP address of the hub and port 4444 in your test code. In TestRay, this is added in the config file where roles for extra users are configured.

  - role: desktopChrome
    seleniumUrl: http://localhost:4444/wd/hub

Here wd stands for WebDriver and hub for Selenium Grid configuration. And wd/hub is part of the uri (node and hub communication).

It is worth noting that there may be situations when a web application asks for a login verification (a security test to determine whether or not the user is human), for example, image verification or CAPTCHA. One workaround is to use cookies, so the user does not need to log in again. This can be done by providing TestRay (and therefore chromedriver) with the path to the Chrome user data directory. This path depends on the desktop platform:

For Linux: ~/.config/google-chrome/Default
For macOS: ~/Library/Application Support/Google/Chrome/Default
For Windows: %LOCALAPPDATA%\Google\Chrome\User Data

The path should then be added in the config file of your project, under the role of the specific user, as the –user-data-dir argument inside chromeOptions (Chromium Command Line Switch to use when starting Chrome).

The bottom line

Based on the technology at hand and your overall knowledge, it is possible to combine and use what you have to streamline your tasks when performing automated testing and find modern solutions to your modern problems. TestRay helps software testers to simplify writing test scripts, so you can easily combine web and desktop app automation capabilities and roles in one configuration file, and write cases for both web and desktop applications in one project using the respective action types and UI element selectors for your tests.