General

[[anonymous: TJ sez - because batch_test.pl no longer runs more than a single test, much of what this page says is wrong and needs to be updated]]

batch_test.pl runs the test suite . It can start up its own personal HTCondor and use that for testing. The tests may also start their own personal Condors.

  1. Build, install and configure your code from HTCondor source tar ball: 
    extract tar ball
cd into source tree(eg condor-7.9.4)
(You must have cmake)
./configure_uw
make install
make tests
cd release_dir
export PATH=`pwd`/bin:`pwd`/sbin:$PATH
LD_LIBRARY_PATH=`pwd`/lib:`pwd`/lib/condor:$LD_LIBRARY_PATH
cd ..
cd src
cd condor_tests
cp -r ../condor_examples/* .
mkdir /tmp/testsockets
echo "/tmp/testsockets" >SOCKETDIR
# run a single test
./batch_test.pl -d . -t cmd_q_shows-name

  2. Testing from the GIT repository, out of tree/out of repository in a directory called outoftree: 
    make a directory to build and test in, cd there
/{repo}/CONDOR_SRC/configure_uw /{repo}/GIT/CONDOR_SRC
    If this is a from scratch build where release_dir(install target) does not exist now. before you start the build adjust your path to have the new bin and sbin at the front of your path similar to this: /pathto/outoftree/release_dir/bin:/pathto/outoftree/release_dir/sbin. This will ensure that build of the tests uses the correct condor_compile for building standard universe tests. Point your environment variable CONDOR_CONFIG to /pathto/outoftree/release_dir/etc/condor_config. UNSET your LD_LIBRARY_PATH but be ready for it to be /pathto/outoftree/release_dir/lib:/pathto/outoftree/release_dir/lib/condor 
    make install
    Now enable the LD_LIBRARY_PATH mentioned above. 
    make tests
cd release_dir
mkdir man
./condor_install --make-personal-condor
source condor.sh
export PATH=`pwd`/bin:`pwd`/sbin:$PATH
export LD_LIBRARY_PATH=`pwd`/lib:`pwd`/lib/condor:$LD_LIBRARY_PATH
cd ..
cd src
cd condor_tests
cp -r ../condor_examples/* .
mkdir /tmp/testsockets
echo "/tmp/testsockets" >SOCKETDIR
# run a single test
./batch_test.pl -d .  -t cmd_q_shows-name

With shared port on, the socket daemon path is too long so the current test code looks for the file SOCKETDIR in condor_tests and uses that as the base location for the new folder for shared port sockets. This is true for master branch after the creation of V8_3_0. This will be removed when no longer needed and this section will be updated.

  1. Results after batch_test.pl completes: 
    249 successful, 34 failed

The file failed_tests contains the list of tests which had a non-zero return code meaning they failed. The file successful_tests will list the tests which had a return value of zero

Running a single test

You can run a single test by specifying extra command line parameters. For example, to run cmd_q_shows-name: 

 ./batch_test.pl -d .  -t cmd_q_shows-name

This is useful if you see a specific test failing in one of the automated builds (http://submit-2.batlab.org/results/continuous.php).

Stress testing in batch_test.pl

Sometimes a test will run in build workspace but not in the batlab. The batlab runs multiple tests at once and thus responsiveness to individual tests is less predictable. One way to duplicate this is to run multiple tests at once within batch_test.pl. 

batch_test.pl watches the list "list_quick" when you do not use "-t testname".

Assuming you can run multiple copies of the test which fails intermittenly at the same time, you can run as many as you want at once. Note however that some names might be used the same so the best best is to run another test as the load and one of the test you are working to fix. In this example I want to stress test job_dagman_fullremove for issues relating to runCondorTool getting the queries we want.

Fill list_quick with: 

job_dagman_fullremovejob_basic_kill
job_basic_kill
job_basic_kill
job_basic_kill

The following command will start job_dagman_fullremove and then 3 job_basic_kill and they will all run at once. 

./batch_test.pl -d . -e 4 (run four from list at a time)

The test suite is prone to leaving HTCondor daemons, especially if you interrupt the tests. After running tests, check for unexpected condor_masters running and kill them.

Warnings, Problems, and Workarounds

See #1124 for tickets associated with improving tests.