Deciding on the right testing tool for a desktop app, might be a difficult task. These are the-Pros and Cons of 8 different open source test automation tools for desktop applications, written in WinForms/ WPF: AutoIT. AutoIT is a Stand Alone (doesn’t require any configuration) and small footprint tool, that simulates mouse and keyboard clicks.
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: Comparing with AutoIt , 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 9/8/2010, 20:56 น. On Tue, 10 Aug 2010 20:05:12 +1200, Lawrence D'Oliveiro wrote: In message , 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 tasksnot 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.
You might even have heard of one of them. I hear that it's moderately popular among Linux users.
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 Chien 10/8/2010, 1:52 น. On Aug 10, 5:56 am, alex23 wrote: Alex Barna 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 : 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 Alex Barna Alex Barna 10/8/2010, 3:25 น. On 2010-08-11, Lawrence D'Oliveiro wrote: In message , 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 tasksnot 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. 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 Grant Edwards 10/8/2010, 20:08 น. On 2010-08-11, Lawrence D'Oliveiro wrote: In message, News123 wrote: On 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? In my experience, almost everybody who designes apps for MS Windows. Grant Robert Kern 10/8/2010, 20:11 น.
On 2010-08-10 21:57, Lawrence D'Oliveiro wrote: In message , 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 tasksnot 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?
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 10/8/2010, 20:12 น. Lawrence D'Oliveiro writes: 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? You asked to understand the point of GUI automation.
Alex responded with one (there may well be others) very good point of GUI automation: automated testing of the GUI's behaviour. What you raise here is not the point of GUI automation. Is you understanding of the point of GUI automation improved? - “I turned to speak to God/About the world's despair; But to ` make bad matters worse/I found God wasn't there.” —Robert Frost o) Ben Finney Lawrence D'Oliveiro 10/8/2010, 21:51 น.
In message, Robert Kern wrote: On 2010-08-10 21:57, Lawrence D'Oliveiro wrote: In message , 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?
![]()
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 10/8/2010, 21:52 น. In message, Grant Edwards wrote: 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. Ben Finney 10/8/2010, 22:00 น. Lawrence D'Oliveiro writes: In message, Grant Edwards wrote: 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? Because that behaviour can be different when tested in a way that doesn't involve using the actual program's interface.
The GUI is part of the program's behaviour, remember, and just about any non-trivial GUI program will have quite complex behaviour specifically in its GUI. Is the concept of testing the actual program behaviour really foreign to you? If not, what part of this concept is causing you difficulty? - “Two paradoxes are better than one; they may even suggest a ` solution.” —Edward Teller o) Ben Finney Grant Edwards 10/8/2010, 23:09 น. On 2010-08-11, Lawrence D'Oliveiro wrote: In message, Robert Kern wrote: On 2010-08-10 21:57, Lawrence D'Oliveiro wrote: In message , 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? 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. 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 Grant Edwards 10/8/2010, 23:12 น. On 2010-08-11, Lawrence D'Oliveiro wrote: In message, Grant Edwards wrote: Automated GUI intended to uncover problems in the underlying program functionality.
That???underlying??? Functionality has nothing to do with the GUIthen. Why not test it directly, rather than go through the GUI? Because in many programs thereisnootherwaytotestitdirectly. Yes, that sucks. In the real world most programs suck.
You've still got to test them. 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. 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 10/8/2010, 23:50 น. Lawrence D'Oliveiro writes: I've no idea what you're asking any more.
The above response seems like a total non-sequitur. But the above exchange convinces me that you're asking it in the wrong forum. This no longer has anything at all to do with Python in particular. “Books and opinions, no matter from whom they came, if they are ` in opposition to human rights, are nothing but dead letters.” o) —Ernestine Rose Ben Finney Jean-Michel Pichavant 11/8/2010, 2:47 น.
On Wed, 11 Aug 2010 06:12:49 +0000, Grant Edwards wrote: Automating a GUI isn't done to test how well the GUI works for real users. Or to put it another way. Automated tests aren't useful for usability testing, regardless of whether one is testing a GUI app or a CLI app. It's done mainly for two purposes: 1) Regression testing to make sure that the GUI's behavior (goodbad, or indifferent) hasn't changed since the previous revision.
2) To test the functionality underlying the GUI. I would like to point out that automating GUIs isn't just done for testing purposes, but has other reasons as well. Probably the most common is for the same reason any automation is done, be it writing a script or building a robot: to reduce the amount of manual effort needed to do some repetitive or frequent task. Mouse and keyboard event recording software used to be one of the killer apps for power users back in the days of classic Apple Mac and early versions of Windows. I'm not entirely sure why they've faded away. It seems to have left an empty niche, for power users who aren't comfortable writing shell scripts, batch files or messing about with DBUS, but still want to automate repetitive tasks.
Another common use is automating interactions with web sites via mechanize. Steven Tim Harig 11/8/2010, 5:57 น. On 2010-08-11, Steven D'Aprano wrote: Mouse and keyboard event recording software used to be one of the killer apps for power users back in the days of classic Apple Mac and early versions of Windows. I'm not entirely sure why they've faded away. It It faided away because automation based on on mouse clicks, and to a lesser extent key injection, is very fragile. GUIs are subject to changing in ways that are unpredictable and difficult to detect.
Some GUI widget sets provide some programatic way to access the GUI items directly for testing and debugging purposes; but, that isn't always available in the final product. Another common use is automating interactions with web sites via mechanize. There are better ways of automating web site interactions. You can other generate the GETS and POSTS directly or you can use import the browsers through COM/XPCOM and manipulate the pages using the browser's DOM object.
Grant Edwards 11/8/2010, 7:09 น. On 2010-08-11, Lawrence D'Oliveiro wrote: In message, Grant Edwards wrote:. 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? OK, now you're just trolling. Grant Edwards grant.b.edwards Yow!
I guess you guys got at BIG MUSCLES from doing too much STUDYING! [email protected] 11/8/2010, 9:53 น. CM 11/8/2010, 12:36 น. On Aug 9, 8:10 am, Alex Barna wrote: 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: Comparing with AutoIt , 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)? This is a little late, but you might want to check out Sikuli. Search for it in this forum, there is a long thread about it. It might be a new useful way to write GUI tests. I have no real idea, though.
Che Alex Barna 11/8/2010, 15:45 น. I'm afraid that my first post has not been understood correctly and most of the following posts are OT, as Ben Finney indicated. The GUI automation has a long history, perhaps since the first windowing system was invented. For years I've been doing this using several different technologies/languages.
But to my surprise, this ares is not very.cultivated. by Pythonistas. Many projects (see the link in my first post) have lost the love of their maintainers and have not been updated for years. Except one, pywinauto, which has a recent release in April.
However, the community activity (mailing list) is very low, website and documentation have not been updated for long also. All this freaks me out on adopting a technology like this: - is there still anyone using it? - what if I encounter a problem but no body replies me in the mailing list? Comparing with the rival AutoIt, using a BASIC-like language, which I don't like at all, has hundreads of post in the users' forum everyday. It makes me doubt: is Python the correct language to do GUI automation? P.S.: hopefully it has been clarified, my original intention of the post is not to debate/discuss: -.why. automating GUI?
- whether GUI/CLI is better. the points GUI or CLI is designed for. Obvious they are all OT. Ben Finney 11/8/2010, 17:18 น.
Alex Barna writes: I know that this question has been asked for several timesSo what happens to this field (Windows GUI automation with Python)? Alex Barna writes: It makes me doubt: is Python the correct language to do GUI automation? Your questions are definitely on-topic here. However, you might want to make use of the “testing-in-python” forum where your questions are even.more. on-topic:-) - “We are stuck with technology when what we really want is just ` stuff that works.” —Douglas Adams o) Ben Finney Roberto Salazar 21/3/2011, 12:48 น. Oh don't be obtuse, dude. GUI automation is much used for webbots and data scraping bamong other things.
Why do you think so many sites are starting to use that irritating 'Captcha' technology? To block GUI-manipulating scripts, of course.
Though, for blind people Captcha makes navigation on some sites quite difficult if not impossible. With scriptable OSes, sites and browsers you can grab a lot of data. On Monday, August 09, 2010 8:10 AM Alex Barna wrote: 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: Comparing with AutoIt , it has tens to hundreds of posts everyday. AutoIt uses a proprietary BASIC -like language, and to be honest, I do not 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)? On Monday, August 09, 2010 11:56 PM alex23 wrote: 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? On Tuesday, August 10, 2010 4:05 AM Lawrence D'Oliveiro wrote: In message Barna wrote: 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 Tuesday, August 10, 2010 4:52 AM Chien wrote: 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)? I'd say pywinauto. It is more O-O than the other tools.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |