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*/cthulhu/docs/doc-set/cthulhu.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 cthulhu 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 'cthulhu' user on your machine and run the tests while logged in as that user. It's best if you check the cthulhu 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> where the *.keys file contains keystrokes and 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 *.cthulhu 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 cthulhu'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 ~/cthulhu/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 ~/cthulhu/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.