Dear all,
This is (again) an announcement for a tool that has existed for some
time but hasn't been listed here before. The current release has only a
couple of minor bugfixes to version 1.4 but as TextTest (previous
message) depends on it I tend to release both at about the same time.
Regards,
Geoff Bache
About PyUseCase (See also
http://www.texttest.org/index.php?page=concepts&n=xusecase):
=============
PyUseCase is a record/replay layer for Python GUIs. It consists of two
modules: usecase.py, which is a generic framework for all Python GUIs
(or even non-GUI programs) and gtkusecase.py, which is specific to PyGTK
GUIs. See www.pygtk.org for more info on PyGTK.
The aim is only to simulate the interactive actions of a user, not to
verify correctness of a program. Essentially it allows an interactive
program to be run in batch mode. Another tool is needed for verification
of behaviour, for example TextTest, also available from SourceForge.
The idea of a "use-case" recorder is described in some detail in a paper
at http://www.carmensystems.com/research_development/articles/crtr0402.pdf
To summarise, the motivation for it is that traditional record/replay
tools, besides being expensive, tend to record very low-level scripts
that are a nightmare to maintain and can only be read by developers.
This is in large part because they record the GUI mechanics rather than
the intent behind the test. (Even though this is usually in terms of
widgets not pixels now)
Use-case recorders like PyUseCase are built around the idea of recording
in a domain language via the developer setting up a mapping between the
actions that can be performed with the UI and names that describe what
the point of these actions is. This incurs an extra setup cost of
course, but it has the dual benefit of making the tests much more
readable and much more resilient to future UI changes than if they are
recorded in a more programming-language-like script.
Another key advantage is that, because we instrument the code anyway to
create the above mapping, it is easy to tell PyUseCase where the script
will need to wait, thus allowing it to record "wait" statements without
the test writer having to worry about it. This is otherwise a common
headache for recorded tests: most other tools require you to explicitly
synchronise the test when writing it (external to the recording).
Example recorded usecase ("test script") for a flight booking system:
wait for flight information to load
select flight SA004
proceed to book seats
# SA004 is full...
accept error message
quit
--
http://mail.python.org/mailman/listinfo/python-announce-list
Support the Python Software Foundation:
http://www.python.org/psf/donations.html
