AutoIt via WebDriver API / JSONWireProtocol? AutoIt version of Appium?

[daluu]

It's interesting there was work to create a client language binding to Selenium / WebDriver as discussed here:

'?do=embed' frameborder='0' data-embedContent>>

I'm wondering if anyone ever considered or have interest in something like an AutoIt (Selenium) server, that is a Selenium/WebDriver server that instead of driving Selenium for whatever browser, it drives AutoIt. 

Basically like the Appium project, but instead of for iOS/Android, it's for Windows UI automation via AutoIt. Instead of using AutoIt language or the ActiveX/COM interface or (C++) DLL interface to AutoIt, we can use whatever WebDriver language binding we prefer and can do things like

driver.findElement(By.name("AutoIt UI control name")).click();

driver.findElement(By.name("AutoIt UI control name")).sendKeys("testing 123");

and we'd only support a subset of the WebDriver API that AutoIt can work with (click, sendKeys, timeouts, and whatever else is suitable)

and for location strategies we can map between WebDriver and AutoIt (per the AutoIt docs) as follows

By.name - the internal .NET Framework WinForms name (if available)

By.className - The internal control classname such as "Edit" or "Button"

By.cssSelector - override expectation of CSS and instead make it to mean (in AutoIt) - REGEXPCLASS - Control classname using a regular expression

By.id - The internal control ID. The Control ID is the internal numeric identifier that windows gives to each control. It is generally the best method of identifying controls. In addition to the AutoIt Window Info Tool, other applications such as screenreaders for the blind and Microsoft tools/APIs may allow you to get this Control ID

By.linkText -  the text on a control, for example "&Next" on a button

all other by methods ignored/not supported. Could also make By.Xpath simply an alias to By.cssSelector above.

I think this type of solution offers a good way to integrate AutoIt with Selenium/WebDriver/Appium/ios-driver tools for a system integration type test or where those tools are lacking that AutoIt complements. Something more powerful and flexible than BlueDuckSDA (http://sourceforge.net/projects/blueducksda/, unless of course you are a hard core AutoIt/VBScript language user) and which would work over local/remote/grid deployments.

 

This would be in essence, building a WebDriver server interface to AutoIt so that WebDriver clients can call AutoIt as if it was a WebDriver with minimal code changes on the client side to support.

 

I have plans to build such a solution but haven't gotten around to this.

 

Let me know what you think of this.

[daluu]

Also, we'd map AutoIt window handling to WebDriver window handling as well

[f00nth]

 

It's interesting there was work to create a client language binding to Selenium / WebDriver as discussed here:

'?do=embed' frameborder='0' data-embedContent>>

I'm wondering if anyone ever considered or have interest in something like an AutoIt (Selenium) server, that is a Selenium/WebDriver server that instead of driving Selenium for whatever browser, it drives AutoIt. 

Basically like the Appium project, but instead of for iOS/Android, it's for Windows UI automation via AutoIt. Instead of using AutoIt language or the ActiveX/COM interface or (C++) DLL interface to AutoIt, we can use whatever WebDriver language binding we prefer and can do things like

driver.findElement(By.name("AutoIt UI control name")).click();

driver.findElement(By.name("AutoIt UI control name")).sendKeys("testing 123");

and we'd only support a subset of the WebDriver API that AutoIt can work with (click, sendKeys, timeouts, and whatever else is suitable)

and for location strategies we can map between WebDriver and AutoIt (per the AutoIt docs) as follows

By.name - the internal .NET Framework WinForms name (if available)

By.className - The internal control classname such as "Edit" or "Button"

By.cssSelector - override expectation of CSS and instead make it to mean (in AutoIt) - REGEXPCLASS - Control classname using a regular expression

By.id - The internal control ID. The Control ID is the internal numeric identifier that windows gives to each control. It is generally the best method of identifying controls. In addition to the AutoIt Window Info Tool, other applications such as screenreaders for the blind and Microsoft tools/APIs may allow you to get this Control ID

By.linkText -  the text on a control, for example "&Next" on a button

all other by methods ignored/not supported. Could also make By.Xpath simply an alias to By.cssSelector above.

I think this type of solution offers a good way to integrate AutoIt with Selenium/WebDriver/Appium/ios-driver tools for a system integration type test or where those tools are lacking that AutoIt complements. Something more powerful and flexible than BlueDuckSDA (http://sourceforge.net/projects/blueducksda/, unless of course you are a hard core AutoIt/VBScript language user) and which would work over local/remote/grid deployments.

 

This would be in essence, building a WebDriver server interface to AutoIt so that WebDriver clients can call AutoIt as if it was a WebDriver with minimal code changes on the client side to support.

 

I have plans to build such a solution but haven't gotten around to this.

 

Let me know what you think of this.

 

 

Hey I saw your post and I'm also running into the same issue (having to automate Windows Authentication from a Selenium WebDriver test). Have you made any progress regarding this since August?

Thanks

[daluu]

It's been long overdue, but I finally took the initiative to do something. And here's the result:

https://github.com/daluu/AutoItDriverServer

It's not Selenium Grid compatible yet, but hey, it's a start. You'll want to look at the Selenium integration demo in sample code section, which does show example of HTTP authentication and file upload handling with AutoIt while the rest of browser handling was done by Selenium.

[JohnOne]

As interesting as this project is, when I weigh up the complexity of it, I cannot really see any benefits.

Selenium is a tool that essentially automates browsers, I've uses it in C++ to automate chrome.

But automating chrome and firefox as well as IE is doable directly from AutoIt now, and in my experience, support for selenium issues was rather poor at best.

However, all things new to work with AutoIt are pretty great.

[daluu]

Well, the point of the project was to allow a user to have the following options when using AutoIt (whether integration with Selenium to handle something Selenium couldn't or for standalone automation):

* not need to execute AutoIt through a process or shell execute in their programming language that calls Selenium.

* not need to compile AutoIt script into a binary for deployment - although longtime AutoIt users may find compile & deploy easier

* not need to deal with another language like AutoIt writing AutoIt au3 script to then compile to binary to then be called by Selenium test to do something

* not need to use COM in their programming language that calls Selenium in order to call AutoIt if not using the compiled binary route

* allow remote deployment of AutoIt when called in Selenium test w/o needing extra tools - Grid deployment, RemoteWebDriver. To illustrate:

Selenium client code runs on host A it targets browser running on host B (via RemoteWebDriver). Now say for AutoIt integration to handle HTTP authentication popup, we need it to run on host B also but executed from host A that runs the Selenium code. The normal shell/process execute won't work as that's local to A. You'll need to add in SSH, telnet, PSExec.exe (or winexe from Linux/Unix) to have host A call the AutoIt compiled binary on host B. Or run the Selenium test directly on host B instead of host A so that it will be local. And in this approach if not executing AutoIt as compiled binary but rather COM, COM isn't network enabled, maybe DCOM?

These cases is where AutoItDriverServer fits in. Deploy that on remote nodes B, etc. Start it up. In Selenium test, fire up another instance of a driver connecting tot AutoItDriverServer, issue AutoIt commands over WebDriver API. No need to compile binary, no COM, already remote enabled. The complexity is more on how the server is implemented. It might seems complex to get the server up and running in the beginning but when you get used to it, it's actually pretty easy (single Python file, that just has Bottle Python module dependency + AutoIt installed or AutoItX DLL registered).

Again it depends on ones preference. But I think this solution works better at scale. If you needed to deploy Selenium AutoIt integrated tests in a distributed and/or grid environment. I did say it's not natively Grid enabled, but there's a way around that. I'll mention it on the project site later on how that works.

[ivanius]

how to use it in autoit?

now i use this Com Object - https://code.google.com/p/selenium-vba/

But this work   me, i don`t know why, all code work prefect in VBAS but not in AutoIT.... 

Edited February 3, 2015 by ivanius

[daluu]

Sorry, for issues with Selenium-VBA - you should contact that project, or post your question to the AutoItX/COM support subforum (or section) of this forum.

And AutoItDriverServer is a separate project. AutoItDriverServer is not for use with AutoIt script. Instead it is the opposite. It allows Selenium users to use/control AutoIt GUI automation from Selenium WebDriver APIs in any language binding/client for WebDriver. So in theory, that means that if these 2 projects below were updated for Selenium 2 WebDriver support

http://bhimarajumavuri.blogspot.com/2010/02/selenium-autoit.html

http://sourceforge.net/projects/blueducksda/

then you can use them to connect to AutoItDriverServer to then use/control AutoIt. But that would actually be silly/idiotic for an AutoIt script user since you are looping over the Selenium WebDriver API in order to use AutoIt from within an AutoIt script language when you could directly use it via the native AutoIt functions without going through WebDriver API. Except in the case of remote deployment, meaning you execute/run code from machine A but the code actually runs on or targets remote machine B. Like how Selenium Grid works. Because there is no AutoIt grid or remote AutoIt code execution natively. You'd have to use options like PSExec.exe, or distributed/remote COM if not using AutoItDriverServer.