What can you expect when you're used to writing test automation for web applications and may now be involved in writing tests for desktop applications?
Desktop automation
- You may have to deal with a splash screen. Solution: poll until you can access the main application window.
- Windows versus macOS. Different UI controls and ability to access them. Test frameworks may only support one OS.
- Custom UI controls and third-party UI controls. Test frameworks may offer partial or no support.
- No headless mode. For headless execution you could use a virtual machine or a display server.
- No implicit wait between application controls, you likely will have to implement your own polling.
- For element selection, you'd be looking for AccessibilityId or element type + name rather than data-test attributes.
- There may be web controls within the desktop application, with data exchanged between desktop and web.
- The installer may have many permutations, for different languages, OSes, and different package contents.
- Desktop UI automation frameworks are very limited compared to web frameworks, and the most maintained ones are rather pricey.
- Slower pipeline execution, due to needing to render all the actual resource-intensive UI and go through native OS APIs.
Note that for many of these considerations, the solution might not involve the desktop UI test framework itself, but rather a separate test harness or set of unit or integration tests.