“A crack team of QA and desktop specialists working at Red Hat is pleased to announce the public release of Dogtail. Dogtail is a GUI test automation framework written in Python that uses Accessibility (a11y) technologies to communicate with desktop applications. Dogtail scripts are written in Python and executed like any other Python program.”
Wow, this looks really cool. The testing scripts are really small and can do amazing stuff. I hope it works with non-gtk apps as well!
A glance at the requirements says that it targets AT-SPI, which (apparently) is Gnome-only right now, currently, at this time.
I believe it should work with Firefox and OpenOffice.org, as well as GTK/GNOME provided that you’re using versions that have been built with accessibility support.
As I understand it, KDE/Qt doesn’t yet support AT-SPI but they’re working on it.
I t3k t2t u3g n5s to s5n w3s (i.e. a11y, i18n) is si11y.
It’s just the adult way of beeing ‘l33t h4><0rz
Yes, at the moment that means GNOME, but KDE4 should be fully-supported when it comes out. Our goal is to have KDE4 support before KDE4 is even released – we’ll be tracking KDE’s svn and writing scripts against KDE apps now that we have some time to let the dust settle from the release.
-clee
Isn’t this already implemented in Qt4?
Maybe i’m not seeing the usefulness of this, but i don’t see what it’ doing other than prining debug statements at the console…which you can do in your app’s code anyway. I guess i’m off track…
Dogtail allows a tester to write scripts that “drive” a user interface and check it behaves as expected. Perhaps this is simple testing, or perhaps it is something more comprehensive like making sure it meets a functional specification.
Modifying the source code is not always a good idea because it can change the behaviour of the application.
What annoys me with open source stuff is when they have video files as swf. Why? Flash is proprietory, I just tried to play the nautilus video in totem and it ate all my memory.
What is wrong with using an open format such as theora? or a tried and trusted and viewable in far more places than flash, mpeg.
A agree; I hate Flash. We’ll have Theora videos up soon.
-zack
w00t I love ogg theoras.
Flash ISN’T proprietory. The spec is open. There are only a few good implementations, though. The best one is closed.
as open as a bank vault. to make use of the specification you have to agree to a license.
Flash ISN’T proprietory. The spec is open. There are only a few good implementations, though. The best one is closed.
Sadly, this isn’t true. The SWF spec isn’t truly open – the license specifically forbids you from using it to make a Flash player, it’s intended for use in adding Flash generation support to your apps only. Thus re-implementations of Flash have to be clean room reverse-engineered in order to be legal.
Why? Because: http://www.unixuser.org/~euske/vnc2swf/
Is one of the best screen recorders around for the X11 desktop. That’s why
. Not to mention, flash plugins are far more widely supported and less argued over than say … mpeg plugins.
$ x11vnc -localhost -viewonly -deferupdate 10 -wait 10 -defer 10 &
$ vnc2swf -nowindow out.swf :0
That’s all you have to do to create a recording of your desktop! No odd requirements.
$ gst-launch-0.8 ximagesrc ! ffmpegcolorspace ! videoscale ! video/x-raw-yuv,width=640,height=480 ! xvimagesink
no odd requirements, just gstreamer. no vnc server needed and you can output it to any format supported by gstreamer instead of the xvimagesink, and as can be seen from that command line do any scaling etc. you want as well.
mpeg less supported? doubtful. there are many video plugins for browsers.
there is also Istambul session recorder that support thora
I admit I just had a very quick glance at their project page, but can’t this kind of thing turn into a cracker’s dream?
I admit I just had a very quick glance at their project page, but can’t this kind of thing turn into a cracker’s dream?
If they can get to the point to install and run an app like this the game is already over.
> Maybe i’m not seeing the usefulness of this, but i
> don’t see what it’ doing other than prining debug
> statements at the console…which you can do in
> your app’s code anyway. I guess i’m off track…
This is not a debugger, it is for automatic regression testing of GUI apps. Let the computer replay a set of test cases and check if everything works fine. How do you want to do that with printf debugging?
There are a few utilities for it, but none of them work very well. I’ve tried one, hated it. It’d be good to have something that’s not just an xevent recorder (which is dependent on the next machine keeping up with your xevents).
But you’re absolutely right that it’s just a test case utility. Because what gui apps STILL lack is a good way to be `make check` compatible.
Gnome finally has GUI testing tool. KDE has had http://www.klaralvdalens-datakonsult.se/kdexecutor/ forever. Functionally its easier to use because it simply records what you do and then plays it back (instead of writing/knowing python.) That said it would really be nice to see Dogtail work for KDE apps as well.
Bobby
Dogtail looks pretty easy to use to me and its completely free, unlike KDExecutor: “…To evaluate or purchase KD Executor…”
“Functionally its easier to use because it simply records what you do and then plays it back (instead of writing/knowing python.”
So if I want to stress test icon redrawing in natilus by moving dozen of them, I should first do it manually ?
Kdexecutor might be good as a macro-recorder for repetitive tasks but is far from being a test automotion framework. It just lacks the flexibility of code-driven tests.
If I have understood correctly, this rocks.
It seems to me much alike Apple’s Automator, maybe one day could get a good GUI to automate the code writting?
Does it not strike people as arrogant for a team of programmers to refer to themselves as a crack team? dogtail is interesting all the same
Great choice on the name, good joke.
Pity they haven’t released a Window$ verion
Seriously, an AJAX project that I’m on needs a GUI-test tool in orcder that we can perform some end-user performance testing.
The in-house tools that we already have seem to barf when the GUI is mostly Javascript artifacts, and everything else out-there which “promises” to do what we need on Window$ requires you to plump the reddies on the table BEFORE getting your hands on it and seeing whether it delivers !!!
I’m currently helping a low-vision intern evaluate accessibility-related features available as a part of GNOME. It is our hope that we can convince IBM to contribute some full-time staff to work on GNOME accessibility, and tools like dogtail will make the pitch a lot easier. One of the major problems in accessibility is proving that all of your widgets, in all possible layouts, work with the speech synthesizer, support keyboard navigation, etc. In particular, accessibility testing on WebSM is a nightmare because we don’t have something like dogtail.
This week we succeeded in getting most of the basic accessibility features working on Linux for the first time. We have full-screen magnification using a virtual framebuffer and GNOME-mag, text-to-speech using Gnopernicus and emacs-speech, in addition to the normal capabilities for changing resolution and font sizes. There are some rough edges because you need to adjust the terminal fonts separately from the GNOME fonts, and GDM can’t selectively start the virtual framebuffer depending on user, but we’re getting there. Ubuntu Breezy has made things pretty easy.
Anyways, this work looks really promising. I’ve always thought that Python would be an incredible force in the future of OSS, and I hope this trend continues.
While I like the idea that suddenly more developers are finally using the accessibility APIs, I hope they won’t deteriorate to testing APIs. It is very important that these APIs follow the needs of disabled people, and don’t follow the needs of testers.