GUI automation tool (windows)

[Alex Barna]

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/PythonTestingToolsTaxonomy#GUITestingTools

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

 

[alex23]

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?

 

[Lawrence D'Oliveiro]

In message

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.

 

[Steven D'Aprano]

In message


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.

 

[Chien]

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

 

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

 

[News123]

On Aug 10, 10:05 am, Lawrence D'Oliveiro > Can’t understand the point
to it. “GUI automation” is a contradiction in

Automating GUI is for testing.

And sometimesfor working around SW, whch has no cli or other interface
and should be automated

 

[Martin P. Hellwig]

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.

 

[Lawrence D'Oliveiro]

In message

On Aug 10, 10:05 am, Lawrence D'Oliveiro


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.

 

[Lawrence D'Oliveiro]

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?

 

[Grant Edwards]

In message


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.

Automated GUI testing isn't intended to uncover those sorts of
problems in GUI design. Automated GUI intended to uncover problems in
the underlying program functionality, and is used mainly for
regression testing to insure that changes made to a program didn't
cause any unintended changes in program behavior.

Automated GUI testing often isn't even being used to test the program
whos GUI is being automated. It's often used to test _other_ programs
with which the GUI-automated-program interacts.

 

[Grant Edwards]

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

In my experience, almost everybody who designes apps for MS Windows.

 

[Robert Kern]

In message


But the most egregious GUI problems are going to be with humans being unable
to figure out how to do something, am I right?

Possibly, but it's not the *only* important problem. Automated GUI testing is
usually a form of regression testing. You want to make sure that the behavior of
parts of the GUI did not change when you made what should be unrelated
modifications to the code.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Robert Kern]

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

People who are not being paid for a CLI or other interface.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Lawrence D'Oliveiro]

Possibly, but it's not the *only* important problem. Automated GUI testing
is usually a form of regression testing. You want to make sure that the
behavior of parts of the GUI did not change when you made what should be
unrelated modifications to the code.

Again, that’s something that primarily affects real users, when they find
some function is no longer in the place where they expect it to be. You have
to test with real users to find out what they think of this sort of thing.

 

[Lawrence D'Oliveiro]

Automated GUI intended to uncover problems in the underlying program
functionality ...

That “underlying†functionality has nothing to do with the GUI, then. Why
not test it directly, rather than go through the GUI?

Automated GUI testing often isn't even being used to test the program
whos GUI is being automated. It's often used to test _other_ programs
with which the GUI-automated-program interacts.

Again, this sounds like it has nothing to do with the GUI per se.

 

[Grant Edwards]

Again, that???s something that primarily affects real users, when they find
some function is no longer in the place where they expect it to be.

Automated testing can detect when some function is no longer where it
used to be.

You have to test with real users to find out what they think of this
sort of thing.

Again, nobody's talking about using automated testing to figure out
what users think. We're talking about using automated testing to make
sure that rev 3.5 acts the same what that rev 3.4 did when you push
button X or select menu option Y.

 

[Grant Edwards]

That ???underlying??? functionality has nothing to do with the GUI,
then. Why not test it directly, rather than go through the GUI?

Because in many programs _there_is_no_other_way_to_test_it_directly_.

Yes, that sucks. In the real world most programs suck. You've still
got to test them.

Again, this sounds like it has nothing to do with the GUI per se.

Exactly! That's what we've been trying to explain. Automating a GUI
isn't done to test how well the GUI works for real users. It's done
mainly for two purposes:

1) Regression testing to make sure that the GUI's behavior (good,
bad, or indifferent) hasn't changed since the previous revision.

2) To test the functionality underlying the GUI.

 

[Lawrence D'Oliveiro]

... nobody's talking about using automated testing to figure out
what users think.

That’s the trouble. What’s the point of a GUI, then?

 

[Jean-Michel Pichavant]

Automated GUI testing isn't intended to uncover those sorts of
problems in GUI design. Automated GUI intended to uncover problems in
the underlying program functionality, and is used mainly for
regression testing to insure that changes made to a program didn't
cause any unintended changes in program behavior.

Automated GUI testing often isn't even being used to test the program
whos GUI is being automated. It's often used to test _other_ programs
with which the GUI-automated-program interacts.

Yep, as an example, I worked on a cardio medical system (X ray). In
order to get to the market, such system must prove its robustness, part
of the proof was about chaining thousands of patients without a crash
nor X ray failure.
This is where GUI automation comes in. The tool was simulating the
interaction between a doctor and the system application GUI and was
working 24/7.

JM