181 lines
7.4 KiB
Plaintext
181 lines
7.4 KiB
Plaintext
ORCA TEST HARNESS:
|
|
------------------
|
|
|
|
This document provides a very brief description of the Orca test
|
|
harness. The Orca test harness is not meant to be our final answer to
|
|
testing, but it helps fill the gap until more general testing for
|
|
GNOME is avaialble.
|
|
|
|
|
|
MAIN IDEAS:
|
|
-----------
|
|
|
|
The main ideas behind the Orca test harness are as follows:
|
|
|
|
* We try to make sure there is a textual description of a test that
|
|
someone can follow by hand when sitting behind the machine. The
|
|
description contains the goal of the test, the procedure to follow,
|
|
and the expected results. We try to keep the description of the
|
|
tests here:
|
|
|
|
http://cvs.gnome.org/viewcvs/*checkout*/orca/docs/doc-set/orca.html#TESTINGPLAN
|
|
|
|
* Each test is intended to be small and test for a specific feature
|
|
of Orca and/or for a specific bug that has been been found and
|
|
fixed.
|
|
|
|
* Orca provides the ability to send a textual description of what it
|
|
is sending to speech and braille. This allows for the recording
|
|
of output, thus allowing for comparison to results in the future.
|
|
|
|
* The harness merely consists of playing back pre-recorded keystrokes
|
|
and comparing Orca's output to a previously recorded successful run
|
|
(where 'success' means Orca output the correct information).
|
|
|
|
|
|
DIRECTORY LAYOUT:
|
|
-----------------
|
|
|
|
The Orca regression tests contained in this directory are laid out as
|
|
follows:
|
|
|
|
./harness: test harness scripts
|
|
|
|
./keystrokes: keystroke and otyher files for playing back tests
|
|
|
|
./results: reference results containing accurate output from Orca
|
|
when the test harness runall script was run using the
|
|
keystrokes
|
|
|
|
|
|
PREREQUISITES:
|
|
--------------
|
|
|
|
The main prerequisite for running the tests is that you've checked the
|
|
orca module out from the GNOME git repository. If you want to do
|
|
regression testing to compare the test results with a known 'correct'
|
|
set of results, you need to create an 'orca' user on your machine and
|
|
run the tests while logged in as that user. It's best if you check
|
|
the orca module out directly in the home directory of the user running
|
|
the tests.
|
|
|
|
|
|
MAIN FILES:
|
|
-----------
|
|
|
|
./harness/runall.sh: The ./harness directory contains two main
|
|
scripts: runall.sh and runone.sh. The runall.sh script is the main
|
|
script to use and will execute all the tests and will place the
|
|
results in a directory whose name is of the form YYYY-MM-DD_HH:MM:SS
|
|
(e.g., 2006-11-29_20:21:41).
|
|
|
|
./harness/runone.sh: The runone.sh script allows a test creator to
|
|
run just one test. The parameters are: <*.keys file> <app-name>
|
|
where the *.keys file contains keystrokes and <app-name> is the
|
|
name of the application to run with the given *.keys file.
|
|
|
|
./harness/user-settings.py.in: contains the default Orca configuration
|
|
settings. The primary thing this file does is disable the use of
|
|
real speech and braille and instead sends a text form of the speech
|
|
and braille to a log file. Note that there are also facilities to
|
|
specify a custom user-settings file for each keystroke file so as to
|
|
allow the testing of Orca settings (e.g., echo by word).
|
|
|
|
./keystrokes/*: The ./keystrokes directory consists of a set of
|
|
directories, where each directory name has significant meaning
|
|
and is used to determine which app the test harness uses for
|
|
testing. The directory name is typically the name of a binary
|
|
on the path. For example, there is a ./keystrokes/gtk-demo
|
|
directory, and the files under this directory are for testing Orca
|
|
using the gtk-demo application. The other type of directory name
|
|
is one that matches the output of 'uname', and is used to contain
|
|
platform specific tests (e.g., Ctrl+Esc for Solaris versus Alt+F1
|
|
for Linux).
|
|
|
|
Under each ./keystrokes/* directory, there will be one or more
|
|
*.keys files. These contain keystrokes recorded using the
|
|
record_keystrokes.py utility (see RECORDING TESTS below). In
|
|
addition, there may be an option *.settings file for each *.keys
|
|
file. The *.settings file is an Orca settings file to use
|
|
specifically for the *.keys file, and is used to help test
|
|
specific Orca features such as word echo, key echo, etc.
|
|
|
|
./results/*: The ./results directory should contain a set of
|
|
directories that matches those in the ./keystrokes directory.
|
|
Under each of the ./results/* directores are *.orca files
|
|
containing the reference speech and braille output from a
|
|
known successful run of Orca using the associated *.keys file.
|
|
|
|
|
|
RECORDING KEYSTROKES:
|
|
---------------------
|
|
|
|
To record a test, you should first start the application to be tested
|
|
and leave it in its initial startup state. For example, if you want
|
|
to write a test for gedit, just start 'gedit' and don't do anything in
|
|
it yet.
|
|
|
|
In a separate terminal window, run orca's 'record_keystrokes.py'
|
|
module and immediately give focus back to the window of the
|
|
application you are testing. You can run the record_keystrokes.py
|
|
module as follows (the 'sleep 5' gives you time to put focus back on
|
|
the app):
|
|
|
|
sleep 5; python ~/orca/src/tools/record_keystrokes.py > myfile.keys
|
|
|
|
Then, interact with the application and press F12 when you are done.
|
|
The F12 tells record_keystrokes.py to quit. If you want to do a rough
|
|
verification that the recorded file is OK, you can run the
|
|
'sanity_check.py' module:
|
|
|
|
python ~/orca/src/tools/sanity_check.py < myfile.keys
|
|
|
|
NOTE: You need to be somewhat careful about recording tests. There
|
|
are cases where some keystrokes do not make it to the AT-SPI, such as
|
|
when applications do keyboard grabs. In these cases, you need to find
|
|
a different way to accomplish what you're trying to do. In addition,
|
|
be aware that some applications also embed time-based and
|
|
username-specific stuff in them. They also sometimes modify their
|
|
menus based upon past use (e.g., a list of recently used documents in
|
|
the 'File' menu). In these cases, you should try to avoid navigating
|
|
through these areas so as to avoid inconsistent output from run to
|
|
run.
|
|
|
|
NOTE ALSO: the test harness automatically starts and kills the
|
|
application to be tested. As such, you usually do not need to record
|
|
keystrokes to exit the application being tested, unless you happen to
|
|
be writing a test for that, of course. Some apps, such as Nautilus
|
|
and Open Office, tend to spawn off or connect to background processes.
|
|
In order to ensure these types of applications quit, you actually do
|
|
need to make sure the keystrokes to quit these applications are
|
|
contained in every keystroke file.
|
|
|
|
|
|
RUNNING THE HARNESS:
|
|
--------------------
|
|
|
|
To run the harness, merely run the runall.sh script. It will run
|
|
through all the keystrokes and compare the results to the known
|
|
results.
|
|
|
|
|
|
KNOWN ISSUES:
|
|
-------------
|
|
|
|
* Solaris and Linux use different keycodes. The keystroke files
|
|
currently are recorded on Ubuntu. The work needed here might be to
|
|
create a directory called ./keystrokes_solaris parallel to the
|
|
./keystrokes directory, and then specify this directory via the "-k"
|
|
command line option to the runall.sh script.
|
|
|
|
* The OS-specific (e.g., 'uname') portions of the harness really do not
|
|
work yet. Instead, the keystroke files are always played regardless
|
|
of platform. We need to work this out.
|
|
|
|
* OpenOffice behaves oddly when popping up dialogs: there seems to be
|
|
a variable delay on these dialogs and the played keystrokes do not
|
|
always seem to get to the right window. You'll be able to tell this
|
|
because OpenOffice will not quit when the test is completed. For
|
|
now, the workaround is to keep rerunning the tests via the runone.sh
|
|
script until the tests complete.
|