This document gives an overview of test procedures for the CCP4i project database handler "dbccp4i" and the underlying code. The tests are divided into different types:
More tests may be added in future.
The following procedures outline manual tests that can be performed to check that the software exhibits the correct behaviours.
Identifier | Name | Description | Procedure & Expected Outcomes |
---|---|---|---|
#1 | Only one handler runs per user | Only one instance of the handler should run for each user of the system. Starting a subsequent instance of the handler should result in control being passed to the existing one, and the subsequent instance should then stop. |
On UNIX/Linux:
|
#2 | Multiple clients | Two clients operating on behalf of the same user should be able to connect to the same handler, and modify and read the same data. |
On UNIX/Linux:
|
#3 | ccp4i/dbhandler compatibility | When running both dbhandler(including its clients) and ccp4i, ccp4i should be able to take control of the database while the handler should be able to read database and reflect the database update which made by ccp4i, but handler shouldn't be able to write to the database. |
On UNIX/Linux:
Exit console by doing exit % exit Disconnecting before exit, please wait... ========================================================== Finished ========================================================== wy45@WY45PORT:~/work/Bioxhit_db/dbccp4i/application> ====================================================================== DB Handler stopped at 2007-03-09 14:57:11.859556 ====================================================================== Exit ccp4i by clicking 'Exit' button. Repeat step 3 & 4. |
The scripts are in the $BIOXHIT_TOP/dbccp4i/test/ directory.
Identifier | Name | Description & Outcomes | Bugzilla No |
---|---|---|---|
Script#1 | rude_client.tcl |
Tests for handler failure on unexpected client disconnection Usage: tclsh rude_client.tcl If the test succeeds then the handler should still be running correctly after the client disconnects. |
#1879 |
Script#2 | dirlock_client.tcl |
Tests for dealing with a lock on user's directories.def file when client attempts to register. Usage: tclsh dirlock_client.tcl If the test succeeds then the handler should deal correctly with the lock it encounters. |
#1860 |
Script#3 | opendb_client.tcl |
Tests for dealing with existing lock on project database when client attempts to open it. Usage: tclsh opendb_client.tcl <project_name> If the test succeeds then the script should report the list of jobs found in the project. |
#1890 |
Script#4 | check_saves.tcl |
Independently monitors saves of the database.def file for a project Usage: tclsh check_saves.tcl <project_name> This monitoring script is intended to be used in conjunction with the console application. It checks periodically on the last modification time of the project in question, and reports when the file has been updated (i.e. rewritten). Ideally writes should only happen when the database content has been updated by the console (or other) application. |
Not assigned |
Script#5 | openclose_client.tcl |
Attempts to close unopened or previously closed projects, and to open projects that have already been opened. Usage: tclsh openclose_client.tcl <project_name> The script attempts to perform the following actions:
The script reports the success or failure for each of these actions, which should all fail if the tests are successful. |
#1888 |
Script#6 | bigrequest_client.tcl |
Operates in one of two modes. In the first (default) mode, it opens the specified project and then submits requests which are longer each time, until the handler fails to return consistent output, giving a rough estimate of the maximum size of the request that the system is able to process through the Tcl client API. In the second mode the user specifies a maximum number of jobs that the system must process, and the script reports whether this number can be successfully processed. Usage: tclsh bigrequest_client.tcl <project_name> [-limit <n> ] [ -adjust_timeout ] In the default mode, the script attempts to perform the following actions:
The script reports the size (in terms of numbers of jobs) of the failing request. If -limit is specified then the script tries a single request with a list of <n> jobs, and reports whether or not this was successfully processed. Notes: This test is of limited use in ascertaining the maximum size of requests that the system can deal with.
For reference: with the default timeout in the iterative mode, the maximum request size on one particular machine. is around 16300 jobs. In the same mode with the adjusted timeout option, the maximum request size obtained is significantly higher (41400 jobs). |
#1921 |
Script#7 | test_dbxml.tcl |
Loads the functions from dbxml.tcl in the ClientAPI directory and attempts various operations to test the functions. Usage: tclsh test_dbxml.tcl The script attempts to perform the following actions:
Note that this script tests the functions directly without invoking the handler or the client API. |
Not assigned |
Script#8 | ccp4icompat_client.tcl |
Attempts to simulate the effect of a second process (e.g. CCP4i) interfering with the project lock and database files while the handler is also accessing the project. Usage: tclsh ccp4icompat_client.tcl <project_name> The script attempts to perform the following actions:
At each step the script attempts to get data from the project to verify that the behaviour is as expected. |
#2089 |
Script#9 | demanding_client.tcl |
Attempts to simulate the effect of a client that generates large numbers of new jobs and other changes to a project in a short space of time (for example, an automated script). Usage: tclsh demanding_client.tcl <project_name> <task_name> The script attempts to perform the following actions:
The script can be edited to adjust the time interval between the creation of new jobs. Multiple instances of the script can be run simultaneously to test the effect of multiple demanding clients, e.g.: #!/bin/sh -e # # Run many instances of the demanding client tclsh demanding_client.tcl JUNK fake1 & tclsh demanding_client.tcl JUNK fake2 & tclsh demanding_client.tcl JUNK fake3 & tclsh demanding_client.tcl JUNK fake4 & tclsh demanding_client.tcl JUNK fake5 & tclsh demanding_client.tcl JUNK fake6 & Warning this script is very messy - it will leave large numbers of "fake" jobs in the project that it is run in. Open the project in CCP4i and use the "Delete/Archive..." options to remove this jobs in bulk. |
Not assigned |
The modules are in the $BIOXHIT_TOP/dbccp4i/test/ directory.
Module name | Description | Usage |
---|---|---|
ccp4ipy_tests.py | Test functions for the ccp4i.py module |
Usage: % python ccp4ipy_tests.py |
dbsocket_crash.py | This script simulates a client application that is designed to crash. In this situation the Python client API should also terminate. (It creates a test situation for reproducing the conditions for bug #2003) |
Usage: % python dbsocket_crash.py <project> <job_id> |
test_addfile.py | This script simulates a client application adding an input file name to a job multiple times. This shouldn't cause a proble, (It creates a test situation for reproducing the conditions for bug #2662) |
Usage: % python test_addfile.py <project> <job_id> <filename> |
test_ccp4i.py | Test functions for the ccp4i.py module built using the Python unittest module. This is a fairly comprehensive set of tests of the directories and database classes for a variety of situations. |
Usage: % python test_ccp4i.py |
test_dbsocket.py | Test XML wrapping and unwrapping functions for the dbsocket.py module, built using the Python unittest module. |
Usage: % python test_dbsocket.py |
CVS Id: $Id: tests.html,v 1.14 2007/10/10 15:16:07 pjx Exp $