Re: [Question/RFE] Automated Testing ?


Subject: Re: [Question/RFE] Automated Testing ?
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Tue Mar 27 2001 - 03:20:02 CST


HI Micheal,
          Scripting Abi would be very easy. All the functions in
ap_EditMethods are accessible via strings passed to a class. If Dom and I
ever find time we'll use this technique to make Abi an embeddable Bonobo
object. After that it would be trvial to produce a testing suite external
to Abi and of course also use Abi for automted report generation, mail
merge, evolope printing, plug into database programs etc etc. All kinds of
fun stuff.

However I'm not sure we want to embed python in Abi. Some of our friends
interested in using Abi on small devices might not like the extra 12
megabytes python would consume.

In any case Hub may get the Mac version going before we get Bonobo going.

Go Hub!

Cheers,

Martin

On Mon, 26 Mar 2001, Michael D. Crawford wrote:

> > Is there an automated systemmatic way of checking that all buttons and
> > menu items within the program work?
>
> Once Hubert gets far enough along with his fine work to bring AbiWord to the
> Mac that doing automated UI testing is worthile - I still want to help on the
> Mac but the consulting business continues to be hectic...:
>
> ftp://ftp.apple.com/developer/Tool_Chest/Testing_-_Debugging/Virtual_User_Tools
>
> yes, this will only test the Mac platform, but having a VU test suite for one
> platform will be a good test for the XP code too. I'm not clear whether or
> not it works on Mac OS X, but I think it probably does as Virtual User is a
> central component of Apple's own testing strategy. And it's now
> free-as-in-beer; you used to have to pay for it.
>
> It is within the realm of possibility that someone could write a test harness
> that accepts plug-ins for communicating with the UI of an app built in any
> kind of framework via a stub that's built into the app for testing purposes.
> Then they could communicate by some kind of RPC protocol.
>
> Such a test harness could be made to work with any application framework if
> the concept of what a UI element was sufficiently abstracted and then you used
> an adapter to bind it to your particular idea of a framework.
>
> What would probably be the quickest way to get something like this running
> would be to link a python interpreter into Abiword, then run the test all in
> one application. It would be best to have the test harness and the
> application under test running as separate programs but then you'd need to
> define a protocol.
>
> You can find out about scripting your application with Python at:
>
> Extending and Embedding the Python Interpreter
> http://www.python.org/doc/current/ext/ext.html
>
> You would "embed" the python interpreter by building it into AbiWord. You
> would "Extend" python by making python peers to AbiWord UI objects, and python
> classes that could serve as containers and descriptions for the UI objects (or
> else copy your existing containment heirarchy into native python tuples and lists).
>
> Python runs on many platforms, not just POSIX but also Mac OS, Windows, BeOS,
> QNX and a number of others.
>
> Note that while scripting AbiWord with something like Python would be an
> admirable way to handle things like automatic generation of formatted reports,
> doing it by simulating button clicks is probably not the way to go about it.
>
> What would work better for end-user scripting is setting and retrieving
> logical properties of documents, as is done in the Apple Object Model and the
> BeOS scripting API (but if you use Python for this the scripts would be platform-independent).
>
> Simulating button clicks and keystrokes by entering them from python scripts,
> though, would be a nice way to do automated user _testing_. And if done the
> right way, it could eventually be done over a TCP connection with some RPC
> protocol, so that you could have a very compact stub in AbiWord, maybe just
> leave it in your beta builds, but the test scripts used in the first phase
> could be used in the second phase without modification.
>
> Mike
> --
> Michael D. Crawford
> GoingWare Inc. - Expert Software Development and Consulting
> http://www.goingware.com/
> crawford@goingware.com
>
> Tilting at Windmills for a Better Tomorrow.
>
>



This archive was generated by hypermail 2b25 : Tue Mar 27 2001 - 03:20:47 CST