«

I know that this question has been asked for several times, but it
surprises that there is no tool under very active development and the
community activities are very low (mailing list posts).

All the tools listed in:

http://pycheesecake.org/wiki/PythonT...UITestingTools

Comparing with AutoIt (www.autoitscript.com), it has tens to hundreds
of posts everyday. AutoIt uses a proprietary BASIC -like language, and
to be honest, I don't like it and I prefer a Pythonic solution.

pywinauto seems to be the best choice but the community has been very
low also. The same happens in pyguiunit, pyAA, WATSUP, all development
seem to be ceased.

So what happens to this field (Windows GUI automation) ?

Alex Barna <alex.lavoro.pro...@gmail.com> wrote:
> So what happens to this field (Windows GUI automation) ?

Either someone cares enough to do something about it, or everyone just
defaults to using AutoIT-like tools.

Which Python implementation are you planning on contributing to?

In message
<56a18e2b-4967-4a63-852e->, Alex
Barna wrote:

> So what happens to this field (Windows GUI automation) ?

Can’t understand the point to it. “GUI automation� is a contradiction in
terms, because a GUI is designed for use by humans to do manual tasks, not
ones that can be automated.

Tasks that can be automated are most easily, flexibly, and above all
reliably, done via command lines and other such scripting interfaces.

On Tue, 10 Aug 2010 20:05:12 +1200, Lawrence D'Oliveiro wrote:

> In message
> <56a18e2b-4967-4a63-852e->, Alex
> Barna wrote:
>
>> So what happens to this field (Windows GUI automation) ?
>
> Can’t understand the point to it. “GUI automation� is a contradiction in
> terms, because a GUI is designed for use by humans to do manual tasks,
> not ones that can be automated.

There have been plenty of systems for recording user actions and playing
them back. They're very useful at times.

http://en.wikipedia.org/wiki/Macro_recorder
http://en.wikipedia.org/wiki/Macro_(computer_science)


You might even have heard of one of them... Emacs. I hear that it's
moderately popular among Linux users.

http://www.linuxjournal.com/article/3769



> Tasks that can be automated are most easily, flexibly, and above all
> reliably, done via command lines and other such scripting interfaces.

That's a matter of opinion, and it clearly depends on the nature of the
GUI and CLI, as well as what task you're trying to automate.



--
Steven

On Aug 10, 5:56*am, alex23 <wuwe...@gmail.com> wrote:
> Alex Barna <alex.lavoro.pro...@gmail.com> wrote:
> > So what happens to this field (Windows GUI automation) ?
>
> Either someone cares enough to do something about it, or everyone just
> defaults to using AutoIT-like tools.

There were a lot of development but then all ceased, except pywinauto
has a final release in April, but really low community activity. Does
it mean AutoIt has much more advantages than Python tools (which I
have not realized) ?

> Which Python implementation are you planning on contributing to?

I'd say pywinauto. It's more O-O than the other tools. Excerpt from
its homepage (http://pywinauto.openqa.org/):

<quote>
Most other tools are not object oriented you end up writing stuff
like:

window = findwindow(title = "Untitled - Notepad", class =
"Notepad")
SendKeys(window, "%OF") # Format -> Font
fontdialog = findwindow("title = "Font")
buttonClick(fontdialog, "OK")

I was hoping to create something more userfriendly (and pythonic):

win = app.UntitledNotepad
win.MenuSelect("Format->Font")
app.Font.OK.Click()
</quote>

Alex Barna

On Aug 10, 10:05*am, Lawrence D'Oliveiro > Can’t understand the point
to it. “GUI automation” is a contradiction in
> terms, because a GUI is designed for use by humans to do manual tasks, not
> ones that can be automated.

Automating GUI is for testing.

On 08/10/2010 12:25 PM, Alex Barna wrote:
> On Aug 10, 10:05 am, Lawrence D'Oliveiro > Can’t understand the point
> to it. “GUI automation” is a contradiction in
>> terms, because a GUI is designed for use by humans to do manual tasks, not
>> ones that can be automated.
>
> Automating GUI is for testing.
And sometimesfor working around SW, whch has no cli or other interface
and should be automated

On 08/10/10 20:13, News123 wrote:
> On 08/10/2010 12:25 PM, Alex Barna wrote:
>> On Aug 10, 10:05 am, Lawrence D'Oliveiro> Can’t understand the point
>> to it. “GUI automation” is a contradiction in
>>> terms, because a GUI is designed for use by humans to do manual tasks, not
>>> ones that can be automated.
>>
>> Automating GUI is for testing.
> And sometimesfor working around SW, whch has no cli or other interface
> and should be automated
>
That and when you are forced using a gui and need to 'copy and paste'
between two programs that have no native bridge except for the one that
is between the keyboard and chair, then it is nice to know that there is
a way of automating it.

--
mph

In message
<abe9b308-db83-4ca8-a71a->, Alex
Barna wrote:

> On Aug 10, 10:05 am, Lawrence D'Oliveiro
>
>> Can’t understand the point to it. “GUI automation� is a contradiction in
>> terms, because a GUI is designed for use by humans to do manual tasks,
>> not ones that can be automated.
>
> Automating GUI is for testing.

But the most egregious GUI problems are going to be with humans being unable
to figure out how to do something, am I right? How are you going to uncover
those problems, except by testing with real people? Automated testing isn’t
going to do it.

In message <4c61a4f5$0$5804$>, News123 wrote:

> On 08/10/2010 12:25 PM, Alex Barna wrote:
>
>> On Aug 10, 10:05 am, Lawrence D'Oliveiro
>>
>>> Can’t understand the point to it. “GUI automation� is a contradiction in
>>> terms, because a GUI is designed for use by humans to do manual tasks,
>>> not ones that can be automated.
>>
>> Automating GUI is for testing.
>
> And sometimesfor working around SW, whch has no cli or other interface
> and should be automated

Who would design software in such a brain-dead way?