Update on WinAppDriver
kat-y opened this issue · 117 comments
Thank you all for your patience, we hear your frustration at the lack of updates on the future of WinAppDriver. In November 2020 we mentioned that development would be paused for at least 6 months. We don’t have a timeframe of when the level of resourcing for WinAppDriver will change as our team is currently focusing on making a great platform for the future of Windows 11 apps – when there is confidence in a timeframe, we’ll definitely share it with you.
We are committed to bringing critical improvements for WinAppDriver to keep pace with other developments in the platform, so it can continue to be used alongside our other advancing technologies. One such improvement is ARM64 support in WinAppDriver v1.3 to ensure alignment with the Windows App SDK. Please feel free to contact me with any further questions or concerns!
Hi @kat-y Thank you for the updates, this really helps boost our morale and continue using WinAppDriver. Here are my questions:
- Any updates on whether the project might go open source? or any intentions to?
- The new build is expected to have issues(due to the shift to .net 5 and also the new platform-specific builds) so how are you planning the testing? I believe @DHowett is the sole resource in WinAppDriver at the moment...
- And I believe there won't be a hard 6 months gap this time?
Thanks once again and hope to see frequent updates. Cheers 😊
our team is currently focusing on making a great platform for the future of Windows 11 apps
I hope we can look forward to a time when the team displays an interest in helping developers ensure their Windows 11 apps are well tested too.
Please have a look to #1556. It is not possible to launch new version of WinAppDriver with Appium
If only I had a penny for every great developer tool that has been stalled due to "more pressing features" 😄. Looking forward to more updates on this repository hope this gets some priority and the community contributions are processed.
Agreed #1610 needs to be a top priority in order to stay in line with latest Appium.
@kat-y this explanation (after 6 months) and the previous ones sound like coming from a cash strapped early stage startup, not a billion dollar company. FFS, hire a few developers and get things moving, this is a critical piece of software! Have a look at the great progress, documentation & perfect developer-relations at the https://playwright.dev/ team, also at Microsoft. When you abandon software like this you make developers disillusioned with native Windows apps, and thus moving to develop using other tools. Remember this: https://www.youtube.com/watch?v=Vhh_GeBPOhs
FYI: microsoft/playwright#10291 - perhaps the two teams could join forces?
@kat-y Hi Katy - my company is considering a move to Selenium w/WinAppDriver for desktop testing. We're of course interested in the long term viability of WinAppDriver and need a clear picture of what the situation current and future is. Any way of getting in touch with you directly? feel free to mail me at lay at milestone.dk
@kat-y @DHowett This is odd and has caused some confusion. Perhaps it can be added to your plans. Using Selenium in msedgedriver.exe .FindElementsByXPath("*") can be used to find children elements but, here the equivalent syntax is .FindElementsByXPath("*/*").
#669 (comment)
Hi @kat-y!
I'm bumping this again to check on the current state of the project.
If there are insufficient resources on your team or even in any case, it would be great if the source for WinAppDriver itself would be made public so that the community can start maintaining the project.
Edit: Maybe I should give a few reasons why maintaining this project is important for many consumers:
- WinAppDriver is largely satisfying the W3C WebDriver standards and thus may be used similarly to other WebDrivers (e.g. the various Selenium WebDrivers and Appium).
- This also means that it is easily possible to provide API wrappers which are platform and WebDriver independent due to API agnosticism.
- WinAppDriver is officially supported as a relay in Selenium Grid 4.
- This means that Selenium Grid 4 can be used to easily distribute and parallelize Windows desktop application UI tests.
- As the official MSDN doc states, Coded UI Test is deprecated and WinAppDriver should be used instead.
We are Visual Studio Enterprise subscription customers. The Coded UI Tests functionality was discontinued for the benefit of using Appium and WinAppDriver.
So we are currently stuck with a project where we cannot even know if it ever will be developed in the future?
FYI: I wrote to about 4-5 main committers of this repo at MS asking for an update. Two of those bounce.
Update: no one answered.
When, if at all, will the source code be made public?
Clearly Microsoft is not addressing issues presented in this status update thread.
Any update as to when any focus will be put back on enhancing the WinAppDriver, resolving existing issues, or making this an open source project?
I would like to pile on here and ask what, if anything, is going to be the automated testing solution for Windows UI applications now that CodedUI is deprecated, and it appears that WinAppDriver is no longer being supported.
Microsoft leaving people high and dry here...
It would be so easy if WinAppDriver itself were open source.
@kat-y: You mentioned some time ago that you guys were looking into open sourcing the code, are there any news regarding this, or an ETA?
I would like to pile on here and ask what, if anything, is going to be the automated testing solution for Windows UI applications now that CodedUI is deprecated, and it appears that WinAppDriver is no longer being supported.
Microsoft leaving people high and dry here...
FlaUI? I've used it very briefly in the past and seems to be a decent alternative. IIRC it's also open source.
I suppose there's always direct UIA coding, but I definitely missed some of the niceties from WAD and FlAUI.
I would like to pile on here and ask what, if anything, is going to be the automated testing solution for Windows UI applications now that CodedUI is deprecated, and it appears that WinAppDriver is no longer being supported.
Microsoft leaving people high and dry here...FlaUI? I've used it very briefly in the past and seems to be a decent alternative. IIRC it's also open source.
I suppose there's always direct UIA coding, but I definitely missed some of the niceties from WAD and FlAUI.
and FlaUI has open discussion/suggestion for interfacing to Selenium/WebDriver. Unfortunately, there's been no real work on it. In case anyone is interested or can contribute in that area.
It's been more than a year now, when can we expect a new release? Please let us know as we have moved towards WinAppDriver, no release for an year, makes us worrisome about our decision.
I would like to pile on here and ask what, if anything, is going to be the automated testing solution for Windows UI applications now that CodedUI is deprecated, and it appears that WinAppDriver is no longer being supported.
Microsoft leaving people high and dry here...FlaUI? I've used it very briefly in the past and seems to be a decent alternative. IIRC it's also open source.
I suppose there's always direct UIA coding, but I definitely missed some of the niceties from WAD and FlAUI.
what's IIRC?
@anunay1 IIRC = If I recall correctly
Is there a way to inquire from Microsoft who to contact about this? Maybe starting from the top executives as needed, and any public communications channels of Microsoft?
Who's the head of MS Open Source initiatives?
Maybe @DHowett has more info?
it seems this project was dead, in face, we still some tool to test desktop application, when this project was active and many people using it, we think it can be make a standard library , but now, i have to found other tool to test our desktop applicaiton.
I am planning to migrate to FlaUI. I have been doing some PoCs with it and it makes what I need, furthermore, it is quite faster.
I can't understand why MS is forgetting WAD. I can't imaging how many windows apps are being developed now in the world and still without a good UI testing tool provided by MS.
Is FlaUI actively maintained, Will it work with UWP apps.
Is FlaUI actively maintained, Will it work with UWP apps.
Well, "actively maintained". Last commit 3 months ago and 3.2.0 Nuget is from 2020 July.
Nuget is not working fine so I have forked master and generate a new Nuget.
Not sure if UWP app is supported, sorry
Paging also past committers @timotiusmargo , @yodurr , @paulcam206 - who is in charge of WinAppDriver? Can we get an update on #1550?
It's quite worrisome that there is absolutely no update on this repository for almost two years now. With the amount of PRs that would be great additions it is annoying.
Is FlaUI actively maintained, Will it work with UWP apps.
Well, "actively maintained". Last commit 3 months ago and 3.2.0 Nuget is from 2020 July.
Nuget is not working fine so I have forked master and generate a new Nuget.
Not sure if UWP app is supported, sorry
New NuGet from FlaUI, FYI. Version 4.0.0, .NET6 compatible. Seems to be active again
FlaUI is sadly missing the W3C webdirver but winapdriver is also missing it so ...
FlaUI is sadly missing the W3C webdirver but winapdriver is also missing it so ...
If I remember all endpoints correctly, WinAppDriver actually implements the W3C WebDriver specs.
Not sure why FlaUI needs to implement anything around WebDriver? The brief bit I've worked with it, it works fine without it.
It doesn't need to, it's just that WebDrivers are more flexible because they can be targeted with any compliant client.
FlaUI with WebDriver interface, from a user perspective would simplify the test automation. You can use single/same API to test web, desktop, mobile. Simplify the code deployment and the learning curve for the test coding. It's a different story if you work solely on desktop automation.
Exactly.
Understood, and agreed to an extent. That was one of the reasons I recommended WinAppDriver when it officially released. But if this is going to be unmaintained and not open sourced, there aren't many other options left. Plus, the learning curve on FlaUI wasn't so high compared to other desktop automation tools (Coded UI, TestStack White, HP QuickTestPro/UFT,) so if it means I at least have an opportunity to help maintain the tool with FlaUI, that's worth it to me for new projects. Unless anything changes here, I'd recommend checking out its capabilities.
Totally agree with @PandaMagnus, in fact I am migrating all my scripts to FlaUI. It is totally unacceptable what Microsoft is doing with WinAppDriver and I am not speaking about pushing new code, but keep the community informed. It is crazy not to have an official test tool working and updated...
https://nutjs.dev/ - not a direct replacement, not exactly the same functionality, but might be useful for some purposes, instead of this abandoned WinAppDriver mess
Looks interesting but not sure it's a real alternative to WinAppDriver because it doesn't seem to have native Windows UI integration and instead focuses on computer vision and mouse/keyboard automation...
Yeah exactly, and there are tons of tools out there that do exactly that already. The special thing about WinAppDriver is that it implements the W3C WebDriver standard.
This is one of those things where irrespective of the situation people just don’t want to lose faith lol.
Yeah exactly, and there are tons of tools out there that do exactly that already. The special thing about WinAppDriver is that it implements the W3C WebDriver standard.
Just wanted to note, tools like those could be (and are) better if we just integrate/wrap them with a W3C Webdriver interface. It is nice when it is native, but the interface wrapping can simply be an external tool. I've already submitted suggestion to do such on the major alternatives. And created PoC W3C WebDriver wrapper implementations for 2 such tools, one being AutoIt, though it's been years so the WebDriver spec support compatibility could be a bit outdated.
Wrapping a UI automation tool around W3C WebDriver spec isn't too hard when you have the integration components ready (e.g. easy translation between tool's native UI mapping and WebDriver spec, REST server interface skeleton framework to build WebDriver API on top of).
Regarding these types of alternative tools, the old/existing ones is understandable, but too bad for any new ones that crop up, the developers often don't consider exposing it via WebDriver spec, it only comes as an afterthought if at all.
Very good points that you are bringing up there, @daluu!
I've also written a few WebDrivers and WebDriver clients, and yes, such tools are a lot easier to wrap than Microsoft's UIAutomation.dll and native libraries.
Another thought for the future: The W3C committee is working on the so-called WebDriver BiDi spec, which I would love to implement for Windows desktop apps if I had more time.
But seeing that there is only radio silence regarding WinAppDriver, it might be best to start investing into this new spec.
Is still research progressing on #1746?
Any update on this issue?
looks like dead end here with WinAppDriver :(
It would be great to have a clear answer - can we count on WAD and invest or just give up and move forward. That's all.
FYI, came across this email looking up Twitter posts, you can try emailing and see if we can get any response: winappdriverteam@microsoft.com. Even Selenium team had some issues making contact, but that was 2021, so things could be worse now.
Reference: https://twitter.com/jimevansmusic/status/1437228175117983752
Thank you all for your patience, we hear your frustration at the lack of updates on the future of WinAppDriver. In November 2020 we mentioned that development would be paused for at least 6 months. We don’t have a timeframe of when the level of resourcing for WinAppDriver will change as our team is currently focusing on making a great platform for the future of Windows 11 apps – when there is confidence in a timeframe, we’ll definitely share it with you.
We are committed to bringing critical improvements for WinAppDriver to keep pace with other developments in the platform, so it can continue to be used alongside our other advancing technologies. One such improvement is ARM64 support in WinAppDriver v1.3 to ensure alignment with the Windows App SDK. Please feel free to contact me with any further questions or concerns!
@kat-y @DHowett @DHowett, and @licanhua
It’s been more than 2 year. please provide an update. Not sure if you are still at Microsoft and looking in to WAD
I just noticed commits from @DHowett, and @smilinrobin @licanhua in 2022, so in terms of best people to ping on Github, would probably be them.
Hi folks. I don't work for Microsoft and am not aware of any updates around the WinAppDriver project.
There is a new initiative started by @licanhua called Ywinappdriver .
It’s calling out some internal decision making too. But this looks abandoned too. Looks like there are resources interested just management there not ready to commit / support.
There is a new initiative started by @licanhua called Ywinappdriver .
It’s calling out some internal decision making too. But this looks abandoned too. Looks like there are resources interested just management there not ready to commit / support.
Thanks for the info, that's very good to know.
Did anyone ever try emailing, winappdriverteam@microsoft.com? I recently did, but I guess it might be a dead unmonitored mailbox. It didn't bounce or return mailbox full at least.
No response. It didn't bounce either
just for information for those who still waiting a miracle.
My team has switched away from this "abandonware" to "self-made" solution. we injected into our winforms and wpf apps a (self made) visual tree walker, build inter process communication between the app and the UI test and we're happy now.
new engine works a lot stable, and by 6x times faster. this work takes only 2 person*month of time. do not wait, seek options, guys!
just for information for those who still waiting a miracle.
My team has switched away from this "abandonware" to "self-made" solution. we injected into our winforms and wpf apps a (self made) visual tree walker, build inter process communication between the app and the UI test and we're happy now.
new engine works a lot stable, and by 6x times faster. this work takes only 2 person*month of time. do not wait, seek options, guys!
Can you share any POC?
just for information for those who still waiting a miracle.
My team has switched away from this "abandonware" to "self-made" solution. we injected into our winforms and wpf apps a (self made) visual tree walker, build inter process communication between the app and the UI test and we're happy now.
new engine works a lot stable, and by 6x times faster. this work takes only 2 person*month of time. do not wait, seek options, guys!
You miss the point, that WAD allows for cross-machine communication which makes it much more scalable and CI/CD friendly. That's why so many people would like to get some update about the roadmap.
@anunay1 I can't, it is not open source. But in general the design is: 1. Visual Tree walker search for controls by their automation name, as we did with WinAppDriver; having the control we may do whatever we want: click on that, check its status, replace text in textbox, get the bounding box to click on it via win32 API etc. Visual Tree Walker for winforms is something trivial. VTW for WPF is accessible as open source - PTAL SnoopWpf. 2. for custom controls (not builtin ones) your VTW must have an "extension points" 3. communication with the test is the last component. Hope it helps you.
@pm90pl IPC we choosed is suitable for cross machine communication too. I just choosed wrong word (inter PROCESS communication), sorry for that! anyway, communication problem is not a strategic problem.
I'm wondering, if any progress to this status update could be had if we keep pursuing Microsoft outside of this GH repo and issue here. Like contact Microsoft by email, phone, social media, attempting to hit the senior management like CEO, CTO, etc. or their PR team, etc. Or trying to engage the news media to assist with this. I've read in newspaper articles, sometimes you get success when you can get the attention of CEO or higher management, or the news reporters involved. At the current pace of pings and approaches, I doubt we'll see any update.
Maybe we even need something like an open source protest at MS headquarters, just to get the message out for an update.
I'm wondering, if any progress to this status update could be had if we keep pursuing Microsoft outside of this GH repo and issue here. Like contact Microsoft by email, phone, social media, attempting to hit the senior management like CEO, CTO, etc. or their PR team, etc. Or trying to engage the news media to assist with this. I've read in newspaper articles, sometimes you get success when you can get the attention of CEO or higher management, or the news reporters involved. At the current pace of pings and approaches, I doubt we'll see any update.
Maybe we even need something like an open source protest at MS headquarters, just to get the message out for an update.
That sounds like something we is the only option now is to petition senior management to atleast get some real updates
This seems to note some executive members of MS
https://news.microsoft.com/leadership/
We can try with https://twitter.com/DHowett on Twitter. Not sure if we could get any response...
Best option is to escalate to Microsoft OpenSource Team at their Twitter https://twitter.com/OpenAtMicrosoft
Best option is to escalate to Microsoft OpenSource Team at their Twitter https://twitter.com/OpenAtMicrosoft
Didn't know this account! I have just pinged them...https://twitter.com/IgorRecioH/status/1645027891615244289?t=NNf0MB2R8Sya83oAloodpw&s=19
An alternative question that the GPT pivot poses in my mind is do we need more than a text box to convey the complexities taken care of by the UI and bring them to the products API? Maybe the next generation apps control complexity and localization tasks will be minimal since properly trained models can extract meaning from any language and recast it to API calls.
An alternative question that the GPT pivot poses in my mind is do we need more than a text box to convey the complexities taken care of by the UI and bring them to the products API? Maybe the next generation apps control complexity and localization tasks will be minimal since properly trained models can extract meaning from any language and recast it to API calls.
Can you please elaborate?
This does not make any sense to me.
Of course there are other approaches to this, but me and many others in here still want to use WinAppDriver for various reasons.
Also, this WebDriver implementation already exists, so why should we re-invent the wheel?
Microsoft could just open-source the code, as there should in any case not really be any secrets hiding in it.
I certainly do not wish to confuse this thread. I also agree this project should be open source because allowing us to update to change is necessary. My hope with the above comment is to retrospect back to our sudden 3 year pause on something as fundamental to app development as UI testing. My intent here is to question what UI testing developments will be necessary (other than the long awaited W3C changes).
Our ui's are a means to encapsolate a complex, useful task and put them into a button.
If the users intent is captured with free text in their native language, and the GPT will translate it to the applications API. Then this is accomplished more seemlessly. (There are methods to fine tune the GPT to only output in a given coding style. Lots of Microsoft docs springing up the last couple of weeks)
Given the above, and the large industry wide pivot, is Microsoft struggling with the question "Is there value of putting effort into updating/extending the UI?"
If the UI is not changing then maybe current testing is enough?
I am not in the know for what Microsoft's plan is, but certainly I understand why they may be slow to update given how the app development landscape has changed.
At the moment we have been testing on Windows 10/11 without large problems. Are greatest challenges are App startup with a splash screen and scrolling to virtual items. Other than that our custom code is minimal and stable to support our very large, diverse application.
Best option is to escalate to Microsoft OpenSource Team at their Twitter https://twitter.com/OpenAtMicrosoft
Didn't know this account! I have just pinged them...https://twitter.com/IgorRecioH/status/1645027891615244289?t=NNf0MB2R8Sya83oAloodpw&s=19
FYI: There is no update, no response, nothing from the official Twitter account of OpenAtMicrosoft. Do we have any other way to contact the team?
perhaps pinging the microsoft/playwright team is an option. I think the PM is active on twitter.
it is not a good look for any open-source test-automation framework from MS given what has happened to winappdriver
This repo might also be interesting, as that team was working on WinAppDriver.
perhaps pinging the microsoft/playwright team is an option. I think the PM is active on twitter.
it is not a good look for any open-source test-automation framework from MS given what has happened to winappdriver
Thank you, Peter. I will ping Debbie, let's see if we get some new info.
This repo might also be interesting, as that team was working on WinAppDriver.
Yep, will check too, thanks!!!
perhaps pinging the microsoft/playwright team is an option. I think the PM is active on twitter.
it is not a good look for any open-source test-automation framework from MS given what has happened to winappdriver
Thank you, Peter. I will ping Debbie, let's see if we get some new info.
This repo might also be interesting, as that team was working on WinAppDriver.
Yep, will check too, thanks!!!
Debbie's response: https://twitter.com/debs_obrien/status/1648059827871010817?t=Whh6e4hVnqehMOh5AsJryw&s=19
Appreciate if any the update available on what roadmap looks like for WinAppDriver
Appreciate the update on what roadmap looks like for WinAppDriver, this will give some confidence to test developers to plan framework designs for big test framework.
Did I miss something?
As far as I can see there hasn't been an update for several years at this point.
@ChristoWolf nothing missed. The above account just opening up issues in repository and seeing if the are closed. Probably just a bot.
Debbie's response: https://twitter.com/debs_obrien/status/1648059827871010817?t=Whh6e4hVnqehMOh5AsJryw&s=19
Did anyone try the Discord server Debbie mentioned in her response? Any luck there?
Debbie's response: https://twitter.com/debs_obrien/status/1648059827871010817?t=Whh6e4hVnqehMOh5AsJryw&s=19
Did anyone try the Discord server Debbie mentioned in her response? Any luck there?
I did yesterday but no success. They told me that Playwright is not an alternative for WAD. We knew that, we only want some info from MS staff, nothing else...
Hello @kat-y! I saw this in a google search trying to find new about WinAppDriver. It say it was updated last week, but the version is 0.3(weird). https://www.microsoft.com/en-US/download/details.aspx?id=51663
Does that mean there is life in the project?
Weird indeed! I have 1.2.1 installed currently. I tried installing this supposed 0.3 version but was told a newer version was already installed.
I guess it's time to ask the question again: what are people using in place of WinAppDriver?
Ranorex, TestComplete, FlaUI, etc.
I personally have started to use https://github.com/FlaUI/FlaUI as many have mentioned before. I have been able to trigger the tests remotely. I still miss being able to controll two computers easily, which would probably make me revisit WinAppDriver in the future, but not being fully open sourced is a really big turnoff.
I wonder if there are any other means to get this publicly debated/discussed (on social media and/or traditional news networks) so that Microsoft would take notice and at least offer some updated PR response.
still not clear if this project is abandoned or not
Abandoned or not, certainly not responsive and seems MS isn't dedicating enough resources to this project in terms of responses to OSS inquiries. Maybe we need to get the press (not social media) involved. Or how do you send inquiry all the way up to MS top execs?