I searched the forum about this topic, but I couldn’t find much information about it. I’m interested in the automation of desktop apps. I did some google research and found interesting tools like “WinAppDriver” and “Winium”. They are interesting for me because they are similar to “Selenium”. Problem is that I couldn’t find much learning resources on YouTube, Udemy or any book or documentation about these tools. Can somebody share some resources with me, or recommended me some better tool?
And one final question. Why there is no so much talking about desktop automation? The majority of automation is about Web or Mobile apps. Desktop automation is not so much used?
Hi Dejan .
Has your desktop app been designed to make it easy to test? (leading question really.)
If not, you are probably looking at a desktop app designed before testing was a thing, however I’m sure that’s not the case here. You have 3 routes open to you essentially.
Free tools that are probably going to be a lot of hard work, and still require you to do your own environment setting up and orchestration
Paid tools, that will do your environment setting up or at least the orchestration/management for you.
My original point, make the application testable, by implementing hook in the application that let you drive the business logic, without the GUI being a thing getting in the way. GUI automation if expensive, you don’t want to be doing that.
Your choices are going to depend a lot on how legacy the application is, how many external systems it interacts with, and how it works with resources and how graphically intensive the application is, in terms of what users use it for. You may want to go with a mix of the 3 approaches I laid out. Which OS are you supporting? Is a good starter question…
Our application is pretty huge. It has a lot of Integration that I test using SoapUI by sending appropriate request messages and waiting for the right response from our app.
I will write you 1 small test case, just to see what I am thinking.
From SoapUI send an appropriate request message.
In application, check that new data from request message are applied.
This was one business process using SoapUI. We also have a lot of processes inside the main application. Like open particular window, draw something, save, close that window, open some other window, change some settings, save, close it, save all… something like that.
Right now we are supporting Windows 10 and Windows Server 2016.
I hope that my post will clarify you what I meant.
Yep Dejan , that is kind of what I had imagined, a varied approach, where you have some component testing going on, via Soap , but also want to still test the UI is showing the results. And doing these together, and separately even. I assume your app has some way of automating logging on and getting to a status page of some sort by using hidden commandline parameters maybe?
For that all toi be completely testable, you need to automate the steps to open any particular form/dialog in question. My experience is that Ranorex is pretty good for this kind of thing. It’s an expensive tool, but if cost is no object, I would go that route.
I am assuming that SoapUI is a bit like Fiddler? I have not used either in anger. You are probably sitting at a confluence of 2 disciplines, Graphical app tests, and web app tests. Graphical app testing is evil, don;t do it. (At least try avoid it.) And steer towards testing the underlying app behaviour using SDKs /interfaces as much as possible. UI testing is painful, and gives very little quality benefit using the tools we currently have generally available.
You need to do some Gui testing, but my approach is to automate everything else to death first, and then do a few hours of manual testing of the UI once per release.
Likely because web & mobile & cloud services are the trend today where most apps are going. You don’t find as much offering for local desktop applications anymore although they still exist more or less. Hence the lack of coverage. On the same note, with that in mind, there is not much Return On Investment (ROI) for tool developers particularly commercial tool developers/companies to improve on & do more with traditional GUI automation tools, so we have what we’ve had for years mostly in that area. On the open source side, there’s more innovation, but it’s still small & less well known because less people work on it, and remember they don’t often get paid for that work, why bother doing more work if the market for desktop UI is small?
WinAppDriver and Winium are the big names, and the ones to look after if you are interested in Selenium WebDriver API for desktop automation. But otherwise, putting that aside, you’d have more options for tools (with their own APIs that differ from Selenium).
