Is WinAppDriver dead?

[dquist]

I am getting the strong impression that this project is getting abandoned by Microsoft.

There are hundreds of open issues with no feedback, and the little triaging that takes place generally seems to consist of the issue being closed without resolution, or a suggestion that a community workaround be added to the wiki.

The last pre-release was over 5 months ago with no release activity since then and no roadmap as to what we should expect.

Is Microsoft still investing in this project or should we look at other tools? It used to be that @yodurr and @timotiusmargo were very active with WinAppDriver, but their GitHub activity have gone almost completely inactive. @hassanuz, the program manager, hasn't had any GitHub activity since November January!

What's going on with this project? If Microsoft wants us to take this tool seriously then there needs to be some sort of roadmap or communication with developers. But there's only radio silence.

[kfrajtak]

Self promo here. If you are interested in a similiar project, have a look at my project https://github.com/kfrajtak/WinAppDriver (in retrospective, I should have chosen different name).

[jsa34]

It would be great if this were able to be open-sourced to allow real community support...

[DLightstone]

You won't get an answer by posting a question here. Not enough public exposure.

The follow-us-on Twitter or Facebook accounts are probably a more appropriate forum

[dquist]

@DLightstone I don't disagree, but doesn't that speak to the fact that there's zero community engagement here? This GitHub project is a ghost town.

I did just discover from Twitter that @yodurr no longer works at Microsoft - he's now at Valve, so that could explain some of it.

[lsoft]

could anyone who have twitter account ask Hassan Uraizee (https://twitter.com/mrhassanuz) about the situation with this project? At general can community do anything to shed some light? I am not strong in such matters...

[DLightstone]

@dquist

Whether there is or is not zero community support is irrelevant.

As I understand things (from https://techcommunity.microsoft.com/t5/testingspot-blog/winappdriver-and-desktop-ui-test-automation/ba-p/1124543 ) WinAppDriver is the recommended test framework.

The absence of responses to questions which only Microsoft employees can answer speaks volumes.

[dquist]

The absence of responses to questions which only Microsoft employees can answer speaks volumes.

Indeed, and I should have been more clear. I mean community engagement from Microsoft, not from outsiders. Microsoft needs to engage with developers here if they want us to take this project seriously.

It would be one thing if this was just a side project, but as you pointed out, WinAppDriver is now the recommended test framework to replace CodedUI.

I suspect that this project was the brainchild of @timotiusmargo who was by far the most active maintainer early on in the project, but has now moved onto other things and no one has replaced him.

[alonrbar]

As I understand things (from https://techcommunity.microsoft.com/t5/testingspot-blog/winappdriver-and-desktop-ui-test-automation/ba-p/1124543 ) WinAppDriver is the recommended test framework.

The post that you mention is quite new (01-23-2020) and someone had just posted a question there a few hours ago. Hopefully upvoting enough here and there may help in getting some answers...

[dquist]

Good find, I upvoted the comment there too.

That one is a recent article, but Microsoft has been saying CodedUI is deprecated and pushing for WinAppDriver as early as 2018. See Coded UI tests.

Here's the snippet from the docs for the deprecation notice which was added in November 2018. https://github.com/MicrosoftDocs/visualstudio-docs/blob/master/docs/test/includes/coded-ui-test-deprecation.md

Perhaps @gewarren could give us some context around this change since she was the snippet author.

[DLightstone]

@alonrbar

New or not it references https://docs.microsoft.com/en-us/visualstudio/test/use-ui-automation-to-test-your-code?view=vs-2019

which contains

Note

Coded UI Test for automated UI-driven functional testing is deprecated. Visual Studio 2019 is the last version where Coded UI Test will be available. We recommend using Selenium for testing web apps and Appium with WinAppDriver for testing desktop and UWP apps. Consider Xamarin.UITest for testing iOS and Android apps using the NUnit test framework.

[alonrbar]

You are right, CodedUI is deprecated for pretty long time now. If you can upvote the comment I pointed out to, or add a comment of your own that would be great. Maybe we'll be able to get Microsoft's attention.

[DLightstone]

I see no reason for beating a dead horse

Community supported efforts only work out when the source coed is available. You simply can't have your cake and eat it.

Upvoting is a waste of time. For the present I am only going to monitor for meaningful posts and solutions

[alonrbar]

I see what you mean there.

Even so, I believe that taking two minutes to vote up for a tool I currently work with on a daily basis worth the long shot of it having some effect. This issue is only 2 days old and already have 7 vote ups, maybe a few days/weeks more will accumulate to something more meaningful.

Cheers

[hassanuz]

Hey everyone,

Just wanted to provide a brief update: we're shuffling a few things around internally with the project. I expect to share more information with you all in the coming weeks.

Thank you for your patience & sorry for the delays!

[dquist]

Hey @hassanuz, thanks for chiming in!

I expect to share more information with you all in the coming weeks.

More information would be great, but having to wait a couple weeks just to get an answer as to whether a project is dead or not... doesn't exactly inspire a whole lot of confidence.

My team has been dabbling in WinAppDriver for ~6 months or so and we're sort of at the point where we either need to commit or go another route. It would be super helpful if you could at least share if this project is still going to be maintained going forward. We've been happy with the project so far, but don't want to get stuck with a dead-end framework.

[ashkaps]

Same for us. Winappdriver is a huge part of our automations. We would like to know if that’s dependable.

[lsoft]

@hassanuz, thanks for reply, but we definitely need a public Microsoft position about the future of WinAppDriver. We invest money and time writing tests with WinAppDriver, but at the moment we are not sure we are not in trouble. (I feel that ghost of silverlight is flying somewhere near :) ) Nevertheless thank for your work on WinAppDriver!

[venkatrao-rgare]

@hassanuz First of all thanks for your work on WinAppDriver. I agree with the comments above. I have spent some time using it with C# and I have also spent some more time using it with Javascript. It would be great if Microsoft can inform us of their intentions with continuing development and support of this tool.

[hassanuz]

Thanks everyone for the feedback. I wanted to circle back and iterate that the project is still active! To add more color: I personally transitioned to a new role at Microsoft. Albeit this, as far as I'm aware, Microsoft is deciding between a few different options (hence the update coming in a few weeks) that all are paths to continuing to move the product forward.

I appreciate everyone’s patience through this and any problems this may have caused.

[dquist]

Hey @hassanuz, congrats on the new role!

And thank you for the confirmation that this project is still alive and on Microsoft's radar. Will eagerly be anticipating further details. 😎

[adrozdowski]

Hi @hassanuz,

I have a question. Maybe you are able to answer me. Are you going to develope UI Recorder? I am asking because unfortunately UI Recorder cannot recognize all controls.

[tdurova]

@adrozdowski if you need the UI recorder to get element locators, I would recommend using these tools:

1. Wpf inspector "https://archive.codeplex.com/?p=wpfinspector"
2. C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\inspect.exe - inspector from Windows SDK

The officially recommended "Accessibility Insights" app is very heavy and hanging.

[RoakyWood]

We are all QA People in one form or another. We expect minimal quality. This is an embarrassing look for Microsoft, they killed CodedUI with this never-updated-out-of-sync-with-selenium-and-appium-and-azure replacement. They even released a WinAppDriver task for Azure (UPDATE! 1. I got a test working on an Azure Pipeline VSTest Release Task! - the secret was to have WinAppDriver Already running or as an always-on service - this avoids the can’t find or attach to open app/process/window whatever error. So it’s a good product - please don’t abandon it, MS! 2. I also got it working by using the Azure Hosted VS 2019 Agent using the canned Azure WinAppDriver Tasks.). They never did an update to replace the long-deprecated desired capabilities. MS needs to wake up and realize that the people here represent companies that spend a lot of money for Microsoft products and for Azure. Get focus back on this project Fulfill your promises. P.S. I don't blame Hassan or Yosef. This is management taking their eye off the prize.

[ghost]

I appreciate the feedback that @hassanuz has provided here, but I find myself in the same situation as other folks; I want to commit to this, because having a "Selenium-like" tool across the board for desktop, mobile, and web testing, makes so much sense. Unfortunately, this driver project, even from its inception, was supported by 1.5-2 people. I hope the upcoming news is worth the wait... like this is being adopted as a formal stream of work in some major team, rather than being supported by 1.5 guys.

[0x7c13]

We are all QA People in one form or another. We expect minimal quality. This is an embarrassing look for Microsoft, they killed CodedUI with this never-updated-out-of-sync-with-selenium-and-appium-and-azure replacement. They even released a WinAppDriver task for Azure (Anyone able to get it to work?). They never did an update to replace the long-deprecated desired capabilities. MS needs to wake up and realize that the people here represent companies that spend a lot of money for Microsoft products and for Azure. Get focus back on this project Fulfill your promises. P.S. I don't blame Hassan or Yosef. This is management taking their eye off the prize.

I remember last summer when I started my Notepads project. I was looking for a solution to run UI tests since there is no way for me to test anything on UWP app logic (and a lot of potential issues I found can only be verified by UI tests). Glad I found this WinAppDriver thingy. But at the time, the docs and samples were all out dated. So I had to fixed them by myself with some extra works. Finally I decided to wait until they update everything so I can add it to my project with confidence. Now almost 1 year past, nothing has been updated at all. Really? My app's user base grows from zero to almost 100k but still, running naked since there is no tests at all. I had to be real careful the whole year last year to make sure I was not going to break anything. Recently I am focusing on refactoring my code but again, tests were missing and progress has to be made with extreme care... I do not want to blame anyone here. I am just feeling super frustrated.

[RoakyWood]

Just to reiterate, everyone here is a MS customer and wants to use MS products to test. We are your friends, not your enemies. Hassan and Yosef created a very nice tool here. We just want to use it for UI testing and be able to use it for CICD testing in Azure.

[lsoft]

WinAppDriver is not dead, but on ventilator :) @hassanuz any news?

[stu4355226]

I mean if Microsoft is not going to maintain or give up on WinAppDriver. At least make it open sourced so community can take over stuff, at least I will do it.

For the past couple years the tools keeps changing and I am tried of doing the same thing over and over again.

It is really awkward when many people asking for it and MS just becomes a dead fish.

[RoakyWood]

To be fair, Hassan said a few weeks, and he seems like a cool cat, so let’s see how it plays out and maybe share help/workarounds in the meantime.

[ghost]

I hope that open sourcing this is part of the plan. Everything else about Selenium \ Appium is open source.

[DLightstone]

When was the last time you worked on a project that did not have a project manager or temporary project manager or staff?

[RoakyWood]

If MS has so little interest in the automated testing community (abandoning CodedUI, Load Testing in VS, Load Testing in Azure almost trimultaneously) you would think they wouldn’t care if it was open source. Maybe there is some other proprietary agreement regarding the UIA adaptability frameworks. They just need to communicate with us, as I wager most of the people on this Issue/Forum are senior and or influential (influence what vendors to use) Test/QA people at major organizations.

[chrisgford]

This is a very valuable tool for Microsoft to also grow its position in the RPA market. I recommend that they dedicate more resources to this project!

[Wolfe1]

@hassanuz Any news here? We are now sitting at half a year since the last code update to the repository. We need to know if this project will be continued or made open source.

[VinayKumar06]

Hoping for some good news on wad with clear roadmap.

[TheHLee]

Agree with everyone here. Still waiting...

[DLightstone]

R.I.P.

[ashkaps]

If MS does decide to ditch this project, can we not fork this and support it as a truly open source project? I am sure there is a huge community of all of us who can support and build this into a great product.

[pradeipp]

Any new updates on this? WinAppDriver is a great tool with an immense probability to be the vscode of Desktop UI testing. The silence is deafening though. Fingers crossed, please update.

@hassanuz @timotiusmargo

[RoakyWood]

Many years ago, my brother worked at a mail handling facility in New Jersey. He watched postal workers stuff mail into a mail slot in the wall every day. When he asked where the slot went, he was told it was an old sealed-up mail room that got closed off in a renovation decades before. This WinAppDriver forum is that New Jersey mail slot. No-one from Microsoft is monitoring this site. We are in... The Twilight Zone.

[fenchu]

I like winappdriver, but it is slow and clunky and the xml returned does not work well with older legacy application, it is in dire need of optimization. TestComplete is a very good alternative but it is $5K/Y.

[VijayHugar]

I like winappdriver, but it is slow and clunky and the xml returned does not work well with older legacy application, it is in dire need of optimization. TestComplete is a very good alternative but it is $5K/Y.

I absolutely agree with your point. We have been running winappdriver for ERP product and its performance is slow and need optimization.

[tdurova]

I don't agree, WinAppDiver works perfect. I use Inspect Object (64-bit UNICODE Release) tool to get locators and this nuget packet for Page Object pattern https://github.com/aquality-automation/aquality-winappdriver-dotnet https://www.nuget.org/packages/Aquality.WinAppDriver/

On Tue, 2 Jun 2020 at 07:06, VijayHugar notifications@github.com wrote:

I like winappdriver, but it is slow and clunky and the xml returned does not work well with older legacy application, it is in dire need of optimization. TestComplete is a very good alternative but it is $5K/Y.

I absolutely agree with your point. We have been running winappdriver for ERP product and its performance is slow and need optimization.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/microsoft/WinAppDriver/issues/1103#issuecomment-637275750, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDWE4UDMH4LY7AUL5W2B5TRUSCEVANCNFSM4LML4GNQ .

--

Best,

Tatiana Durova

tatyana.durova@gmail.com | +4917 3342 4662

[Wolfe1]

I don't agree, WinAppDiver works perfect. I use Inspect Object (64-bit UNICODE Release) tool to get locators and this nuget packet for Page Object pattern https://github.com/aquality-automation/aquality-winappdriver-dotnet https://www.nuget.org/packages/Aquality.WinAppDriver/ … On Tue, 2 Jun 2020 at 07:06, VijayHugar @.***> wrote: I like winappdriver, but it is slow and clunky and the xml returned does not work well with older legacy application, it is in dire need of optimization. TestComplete is a very good alternative but it is $5K/Y. I absolutely agree with your point. We have been running winappdriver for ERP product and its performance is slow and need optimization. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1103 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDWE4UDMH4LY7AUL5W2B5TRUSCEVANCNFSM4LML4GNQ . -- Best, Tatiana Durova tatyana.durova@gmail.com | +4917 3342 4662

Are you testing a UWP/Modern windows application or a legacy WinForms application? Automating something like the WIndows 10 calculator (UWP) is a breeze. Larger WinForms applications on the other hand seems to take quite a bit longer.

[peterainbow]

so i have proven that the current driver when dealing with combo boxes puts the open dropdown popup window in the root of the xml tree below the desktop, this is not correct. why isn;t this thing made open source so we can track and fix these things...

[Wolfe1]

so i have proven that the current driver when dealing with combo boxes puts the open dropdown popup window in the root of the xml tree below the desktop, this is not correct. why isn;t this thing made open source so we can track and fix these things...

That seems to be the behavior of legacy windows apps. I believe this is simply how windows treated combo-box entries in winForm applications. UWP applications work as expected within the dropdown contents.

Easiest way I found to deal with it is to have a desktop session active in the background that I spin up at app launch, switch to it after clicking our combobox selector, get our selection, and then switch back to our main application.

See https://github.com/Accruent/robotframework-zoomba/blob/6eb84441564093153d3fd7d1fa59565961f90c26/src/Zoomba/DesktopLibrary.py#L595

[peterainbow]

so i have proven that the current driver when dealing with combo boxes puts the open dropdown popup window in the root of the xml tree below the desktop, this is not correct. why isn;t this thing made open source so we can track and fix these things...

That seems to be the behavior of legacy windows apps. I believe this is simply how windows treated combo-box entries in winForm applications. UWP applications work as expected within the dropdown contents.

Easiest way I found to deal with it is to have a desktop session active in the background that I spin up at app launch, switch to it after clicking our combobox selector, get our selection, and then switch back to our main application.

See https://github.com/Accruent/robotframework-zoomba/blob/6eb84441564093153d3fd7d1fa59565961f90c26/src/Zoomba/DesktopLibrary.py#L595

yes that's what i do anyway use a desktop session, but the point is that both inspect and the uirecorder say that the path is not rooted on the desktop, but that it's rooted on the combo itself, so one of them is wrong and needs to be fixed

[Wolfe1]

so i have proven that the current driver when dealing with combo boxes puts the open dropdown popup window in the root of the xml tree below the desktop, this is not correct. why isn;t this thing made open source so we can track and fix these things...

That seems to be the behavior of legacy windows apps. I believe this is simply how windows treated combo-box entries in winForm applications. UWP applications work as expected within the dropdown contents. Easiest way I found to deal with it is to have a desktop session active in the background that I spin up at app launch, switch to it after clicking our combobox selector, get our selection, and then switch back to our main application. See https://github.com/Accruent/robotframework-zoomba/blob/6eb84441564093153d3fd7d1fa59565961f90c26/src/Zoomba/DesktopLibrary.py#L595

yes that's what i do anyway use a desktop session, but the point is that both inspect and the uirecorder say that the path is not rooted on the desktop, but that it's rooted on the combo itself, so one of them is wrong and needs to be fixed

Interesting, im using accessibility insights and ui recorder. Both report most combo boxes tested as desktop pane elements unless they are something like the windows 10 calculator that is a UWP app.

https://i.imgur.com/vHhqUJ8.png

Regardless you are right that something needs to be fixed but would require some insight into the code...or a team working on it :pensive:

[peterainbow]

so i have proven that the current driver when dealing with combo boxes puts the open dropdown popup window in the root of the xml tree below the desktop, this is not correct. why isn;t this thing made open source so we can track and fix these things...

That seems to be the behavior of legacy windows apps. I believe this is simply how windows treated combo-box entries in winForm applications. UWP applications work as expected within the dropdown contents. Easiest way I found to deal with it is to have a desktop session active in the background that I spin up at app launch, switch to it after clicking our combobox selector, get our selection, and then switch back to our main application. See https://github.com/Accruent/robotframework-zoomba/blob/6eb84441564093153d3fd7d1fa59565961f90c26/src/Zoomba/DesktopLibrary.py#L595

yes that's what i do anyway use a desktop session, but the point is that both inspect and the uirecorder say that the path is not rooted on the desktop, but that it's rooted on the combo itself, so one of them is wrong and needs to be fixed

Interesting, im using accessibility insights and ui recorder. Both report most combo boxes tested as desktop pane elements unless they are something like the windows 10 calculator that is a UWP app.

https://i.imgur.com/vHhqUJ8.png

Regardless you are right that something needs to be fixed but would require some insight into the code...or a team working on it 😔

and guess what when its inside of an excel addin it works as in a child of the form,,,

[stu4355226]

I guess the "coming update" happened to another universe. RIP WinAppDriver and now it's time to start looking for another alternative ..... and port all the test cases to there.. god..