Update on WinAppDriver

[kat-y]

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!

[pradeipp]

Hi @kat-y Thank you for the updates, this really helps boost our morale and continue using WinAppDriver. Here are my questions:

1. Any updates on whether the project might go open source? or any intentions to?
2. 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...
3. And I believe there won't be a hard 6 months gap this time?

Thanks once again and hope to see frequent updates. Cheers 😊

[mrlacey]

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.

[fforjan]

@kat-y there is simple PR pending from the community like #1539 or #1058

Although I understand you do not want to work heavily on this, could you open and accept some community items like the one previously set ?

[Wolfe1]

@fforjan @kat-y Agreed, at least the PR section should be looked at for now in order to capture any effort the community has done to improve documentation and such.

I have been trying to get some samples added for RobotFramework for over a year now #1148

[SnowISmirnov]

Please have a look to #1556. It is not possible to launch new version of WinAppDriver with Appium

[steffen-wilke]

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.

[liljohnak]

@DHowett @kat-y This seems like it needs to be adressed.
Please evaluate: #1610

[Wolfe1]

Agreed #1610 needs to be a top priority in order to stay in line with latest Appium.

[andrisi]

@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

[andrisi]

FYI: microsoft/playwright#10291 - perhaps the two teams could join forces?

[LYDE1234]

@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

[liljohnak]

@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)

[anunay1]

@kat-y Any update when can we expect the open issues to be addressed.

[ChristoWolf]

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.

[jozefizso]

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?

[andrisi]

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.

[DLightstone]

When, if at all, will the source code be made public?
Clearly Microsoft is not addressing issues presented in this status update thread.

[zannett]

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?

[Wolfe1]

[zannett]

[aronweiler]

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...

[ChristoWolf]

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?

[PandaMagnus]

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.

[daluu]

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?

[igorrecioh]

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...

[timrash-wk]

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?

[jrnewton]

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.

[jrnewton]

I guess it's time to ask the question again: what are people using in place of WinAppDriver?

Ranorex, TestComplete, FlaUI, etc.

[CT4nk3r]

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.

[ChristoWolf]

Bumping and hoping for open source.

@kat-y @DHowett

[daluu]

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.

[RamaNarasimhaChanda]

@kat-y @DHowett can you please share updates here, It will help us to decide what need to be done further and search for alternatives.

[ChristoWolf]

Another day, another opportunity to bump.
@kat-y, @DHowett: Please open source WinAppDriver 😃

[samayo]

still not clear if this project is abandoned or not

[daluu]

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?

[aronweiler]

Yeah, this seems abandoned, which is unfortunate... we're being driven to other options for automated testing, such as Squish, which end up costing a significant amount of money.

[mykola-mokhnach]

Just linking it here if somebody would be interested in maintaining an open-source WAD alternative, which could be used with Appium's windows driver: licanhua/YWinAppDriver#33

The Appium team is also open to alternative proposals on this topic.

[liljohnak]

FYI, As we upgraded our application to NET8 it is still working.

[ChristoWolf]

Bumping again because WinAppDriver does not comply to the newest WebDriver standard specs and is thus not directly compatible with Appium.WebDriver anymore, see in particular this.

@DHowett @kat-y Please consider communicating further plans with us.

[aronweiler]

I find it interesting that MS seems to have abandoned this, because it fits very well with the AI initiatives that they are so deeply involved in. For instance, you could hook up tool calls allowing an LLM to easily use Windows applications without the inconsistency of integrating a vision component.

[ChristoWolf]

@aronweiler I don't really see a connection.
Also, there are several major problems with your idea:

• Any ML algorithm only works (i.e correctly labels) with a certain probability.
  Introducing flakiness just to make it fancy is not the best idea.
• Not sure which problems a large language model would solve.
• The purpose of WinAppDriver is to be W3C WebDriver compliant (at least partially), not to tackle arbitrary UI automation problems.

[aronweiler]

@ChristoWolf have to disagree with all of your points-

• While it is true that machine learning algorithms, including LLMs, can introduce a level of uncertainty due to their probabilistic nature, this does not inherently make them unsuitable for use with WinAppDriver. In fact, LLMs can be used to enhance the capabilities of WinAppDriver by providing natural language processing for complex automation tasks, interpreting user intentions, and generating robust automation scripts. The key is to use LLMs in a way that complements the deterministic nature of WinAppDriver, such as generating XPath selectors or assisting in the creation of test cases (I'm already doing this to great effect).

• WinAppDriver's primary purpose may have been to provide a Windows application automation interface that complies with the W3C WebDriver standard, however this does not preclude its use with additional tools like LLMs. By integrating an LLM, you can streamline the test development process, automatically generate test cases based on natural language descriptions, and even provide intelligent suggestions for test improvements. This doesn't change the core functionality of WinAppDriver but rather extend its utility.

• WinAppDriver may have been designed to work with predefined UI automation tasks, but the integration of an LLM could allow for a more dynamic approach to UI automation. For example, an LLM could understand the context of a UI and generate appropriate automation commands for WinAppDriver, drastically reducing the manual effort required to script complex interactions.

Overall, WinAppDriver + LLM seems to be winning combo, especially for test automation... if MS was interested.

[ChristoWolf]

@aronweiler ok so you are saying that my points are wrong because you would like LLM functionality?

Look, I think LLMs have great use cases, but a WebDriver server implementation is not it.
I think your ideas are absolutely sound, but should be part of a dedicated API and not WinAppDriver.

In any case, Microsoft has abandoned this project, so there will never be any such extensions to this implementation.
IMO the best we can do is to combine forces and try to get somebody to notice this issue and at least communicate with us.

[daluu]

I find it interesting that MS seems to have abandoned this, because it fits very well with the AI initiatives that they are so deeply involved in. For instance, you could hook up tool calls allowing an LLM to easily use Windows applications without the inconsistency of integrating a vision component.

Overall, WinAppDriver + LLM seems to be winning combo, especially for test automation... if MS was interested.

That might be a matter of business goals and priority. AI can span many areas, in the testing space, we have niche 3rd party players that have AI based automation tools. I'm guessing MS doesn't think it is worth the time to compete there. They focus on AI for other uses. If anything, they could just acquire those other niche companies and build upon them.

Things might be different if say Google or Apple took on AI for test tooling (Android test automation, XCode/iOS/macOS test automation, AI for SafariDriver, AI for ChromeDriver, etc.). Then I would think that would get MS's attention. If I'm not mistaken, I don't think Google nor Apple have taken on AI/LLM for their test tooling, at least with respect to WebDriver integration, have they? If one is interested in this area for AI, maybe ask around those company's user/dev communities to see if we can spawn some traction.

[eykh]

I guess it's time to ask the question again: what are people using in place of WinAppDriver?

Ranorex, TestComplete, FlaUI, etc.

After wasting LOTS of time (=money) with CodedUI and WinAppDriver and their stability issues, we went with Smartbear TestLeft. Rock solid, easy to use. The client nuget package still requires the "old" .NET Framework, which is the only annoyance.

Everything nicely integrated in CI/CD of course.

[AnatolyRyzhakov]

Another comment to pay your ATTENTION
@kat-y , please, share the latest news about WinAppDriver
People still waiting for

[ChristoWolf]

We know that this works, but it's a work-around for the fact that WinAppDriver has not seen any development for several years.

Also, I'm pretty sure that the Appium people will at some point stop implementing such compatibility bridges because it is not their responsibility to do so.

[aristotelos]

I have started writing a WebDriver2 implementation on top of FlaUI which might be interesting if somebody is looking for an alternative. It is still open for review: FlaUI/FlaUI#594