Automation testing is always a great challenge for QA engineers, particularly when it comes to less frequently used topics. In such cases, not enough resources can be easily found, and here the challenge comes, where you have to dig deeper to find a way around.
In this blog, I will demonstrate how easy it can be to build your first automation test scenario for a windows app using WebdriverIo .
WebdriverIo is a well-known automation test framework using nodeJS that works as a wrapper for the webdriver protocols, as it provides the required commands and binding for the required API in order to be able to connect to your user agent. No matter if it’s a browser, mobile, desktop app, or WebSocket connection just use the relative service.
Get started
- To establish communication with the Windows desktop app, we require a driver capable of receiving and interpreting WebDriver protocol commands and responding appropriately. For this purpose, it’s essential to have Windows Application Driver (WinAppDriver) pre-installed on our system.
- While it’s possible to establish a direct connection with WinAppDriver, using an Appium server as a proxy is recommended. This approach offers increased flexibility in creating test scenarios as it enables enhanced interactions with app elements. Appium serves as a bridge that allows for better binding with the user agent, ensuring proper interaction with the app’s elements.
3. Conducting our test is dependent on having the right tool for inspecting elements, which allows us to interact with them effectively. The Accessibility tool — inspect used to serve this purpose, but it has now become a legacy tool and has been superseded by Accessibility Insights. This newer tool is more robust and offers a plethora of features, including “FastPass and automated checks.” 💥
4. Set up a WDIO (WebdriverIO) project by either utilizing the `wdio-cli` or by directly adding the necessary dependencies to your existing `package.json`, as illustrated below👇🏽.
In our wdio.conf.ts, we will see appium service is already set there 👇🏽
5. We must define our Appium capabilities, as this is necessary to link your test to the active server instance and instruct it on how to respond.
Capabilities include several essential keys, including:
- “port,” which specifies the server’s running port.
- “path,” which represents the default “/” path to the running session.
- “app,” which indicates the path to the application binaries (e.g., .exe file) or the app name.
- “waitForAppLaunch,” defining the time required for the app to launch before initiating the test.
Inspecting elements and writing test cases
- It’s time to begin crafting our real test scenario. We should launch our application and the accessibility insight tool. Within the properties settings, choose “Include all properties with values.” This selection will enhance your capability to identify the most suitable locator strategy.
2. Just hover your cursor over the element you want to interact with, and you’ll notice that the AI app detects it. You can choose from various methods to specify your locator strategy. You can either use AutomationId, which is akin to HTML’s Id attribute, or utilize Xpath to define the correct path for your element. Check out the example below 👇🏽.
3. Write your test step
4. Finally, write your test with the relevant assertion
Execution
Wow, seems working 👏
Conclusion
Automating a desktop app may appear somewhat similar to automating a web app, but it entails distinct configurations and a different approach to orchestrating the framework. Inspecting elements, writing complex test cases and handling hooks can be challenging and necessitate proper optimization. Building a CI/CD pipeline can also be a challenging task, which we will dive into further in upcoming blog posts.
Thank you for stopping by and reading my blog, hope it was useful & stay tuned for the new upcoming interesting blogs...
