[TIP] Python GUI testing

Geoff Bache geoff.bache at gmail.com
Wed Apr 6 12:40:06 PDT 2011


Thanks to everyone who replied to this thread - some interesting tips and ideas.

I thought it was about time I replied to my own question and said
something about what we do in this area. I've worked for a long time
with a non-programming test department and PyUseCase is my attempt to
build a tool that is easy for testers to use but which also produces
readable and maintainable tests. The main things it offers over and
above most other open source UI testing tools is
- a domain language for describing tests (which then read as "use
cases", hence the name)
- a recorder which can record in this language and which doesn't
become useless if you refactor the tests

It's now been implemented for four different toolkits (the 3 python
ones I mentioned, and also SWT/Eclipse RCP using Jython. Work to
support Swing is underway) and have tried to build on top of tools
like some of the ones mentioned on this thread where they exist. It's
proved to be a pretty useful way to get testers and developers working
together on the same acceptance test suite and has worked very well
for us so far with minimal effort to handle even quite large UI
changes.

(More info available at http://www.texttest.org/index.php?page=ui_testing,
step by step tutorial with screenshots at
http://www.texttest.org/index.php?page=documentation_3_21&n=gui_tests)

Regards,
Geoff

On Wed, Apr 6, 2011 at 9:12 PM, Gary Bernhardt <gary.bernhardt at gmail.com> wrote:
> On Wed, Apr 6, 2011 at 4:11 AM, Michael Foord <michael at voidspace.org.uk> wrote:
>> Right, but relying on ordering makes your tests fragile to UI changes -
>> which is particularly an issue when you're doing TDD and adding features to
>> an app. (I'm not questioning your assertion that it worked fine for you Gary
>> - just making a general point.)
>>
>> Walking the controls in a view until you find the right one (with the right
>> contents for example) as you describe is a good way to mitigate against
>> this. On the other hand being able to name controls and then find them in
>> the view by name is a useful way of not being dependent on ordering. This
>> was the approach (or one of the approaches) we took at Resolver Systems.
>
> Very true—I'd definitely go with control names if possible. I'm
> slightly less afraid of building tests without them now, though. :)
>
> --
> Gary
> http://blog.extracheese.org
>



More information about the testing-in-python mailing list