1: in src, make release
2: in src, make testbin
3: in condor_tests, make all
-3: make certain that the condor binaries you want to test are on your path, e.g. set path=(../release_dir/bin ../release_dir/sbin $path)
+3: make certain that the HTCondor binaries you want to test are on your path, e.g. set path=(../release_dir/bin ../release_dir/sbin $path)
4: in condor_tests, ./batch_test.pl -b
_This will run the binaries in your path configured with samples generic configs from condor_examples with slight changes added to the end of the condor_config.local file_
**About the test suite**
-The condor test suite lives in src/condor_tests
+The HTCondor test suite lives in src/condor_tests
There's no toplevel Makefile (src/Imakefile) rule that builds and runs all
of this.To build and run the test suite see section above. We will get into variations later.
@@ -25,8 +25,8 @@
batch_test.pl by default assumes you want to test with daemons found in your path and assumes they are currently running with your current configurations. This allows having a daemon in a debugger during the testing if needed.
-batch_test.pl knows how to create a new test personal condor from the binaries in your path using slightly modified generic configuration files. It creates the
-directory condor_tests/TestingPersonalCondor and sets up to run there. Sometimes to restart tests you may need to remove this directory so it knows to restart the personal condor.
+batch_test.pl knows how to create a new test personal HTCondor from the binaries in your path using slightly modified generic configuration files. It creates the
+directory condor_tests/TestingPersonalCondor and sets up to run there. Sometimes to restart tests you may need to remove this directory so it knows to restart the personal HTCondor.
batchtest.pl runs tests serially one after another by default.
@@ -36,7 +36,7 @@
./batch_test.pl
-To set up the environment(including the personal condor) and then run the entire
+To set up the environment(including the personal HTCondor) and then run the entire
suite:
./batch_test.pl -b
@@ -55,19 +55,19 @@
batch_test.pl takes multiple arguments:
- -b <build&test> Use generic config files from condor examples
- and start a personal condor.
+ -b <build&test> Use generic config files from HTCondor examples
+ and start a personal HTCondor.
-d <directory> Run the tests in this directory, ie "-d gcc/"
-s <filename> Skip all the tests listed in <filename>
-f <filename> Run all of the tests listed in <filename>
-a <count> Run each test this many times
-t <test> Run just this test
- -p <pretest> Just set up the testing personal condor
+ -p <pretest> Just set up the testing personal HTCondor
-e <evenly> Run the tests concurrently
- -w <wrap> Wrap each test in a personal condor or with -t just one
+ -w <wrap> Wrap each test in a personal HTCondor or with -t just one
Run all the top level tests( standard way for windows ) with
-a pristine personal condor.
+a pristine personal HTCondor.
./batch_test.pl -d . -b
@@ -80,12 +80,12 @@
**Simple tests vs wrapped tests**
-We wrap tests because we want to change the environment(config settings) used while this test is running without impacting the other tests which are either running now or will run yet in the main personal condor. It also ensures that
+We wrap tests because we want to change the environment(config settings) used while this test is running without impacting the other tests which are either running now or will run yet in the main personal HTCondor. It also ensures that
there will be a log directory showing only what is going on during this test.
-With many tests running in the starting personal condor it can be hard to see what is going on. There are two ways to get a test wrapped:
+With many tests running in the starting personal HTCondor it can be hard to see what is going on. There are two ways to get a test wrapped:
1: Run test with batch_test.pl -d . -w -t job_core_output_van -b
-2: Write the test to start a personal condor and then run its test
+2: Write the test to start a personal HTCondor and then run its test
The following files are the most basic test which is wrapped and can be run ./batch_test.pl -d . -t wrapped_test -b. See "Adding a test" below for help in writing the actual test. Below are the pieces:
@@ -93,18 +93,18 @@
*: wrapped_test.run - Script run to perform the test
*: x_wrapped_test_locconfigpostsrc - The items you want to be at the end of the local config file
*: wrapped_test.pl - The core test itself with call to RunTest
-*: x_param.wrapped_test - Parameter file to control personal condor and which daemons to run
+*: x_param.wrapped_test - Parameter file to control personal HTCondor and which daemons to run
**Concurrent Testing**
1: Under V7_2-branch ./batch_test.pl -e 30 -b means try to keep thirty running at once if there are that many in the current directory(or left to do).
-2: Under V7_3.1 and newer -branch ./batch_test.pl -w -e 30 -b means try to keep thirty running at once if there are that many in the current directory(or left to do). Wrap each test in a personal condor to check every test for core and ERROR.
+2: Under V7_3.1 and newer -branch ./batch_test.pl -w -e 30 -b means try to keep thirty running at once if there are that many in the current directory(or left to do). Wrap each test in a personal HTCondor to check every test for core and ERROR.
**Core file and ERROR detection**
1: Under V7_2-branch None
-2: Automatic and done in CondorTest for all cases but concurrent testing without wrapping tests in personal condors. Tests with personal condors are always checked as are tests run sequentially in the outer testing personal condor.
+2: Automatic and done in CondorTest for all cases but concurrent testing without wrapping tests in personal condors. Tests with personal condors are always checked as are tests run sequentially in the outer testing personal HTCondor.
@@ -166,12 +166,12 @@
Actually writing your test code is very easy. The first thing to think about is
what are you trying to test. Most of the compiler directory tests in the current
-test suite are designed to test the remote system calls or checkpointing of Condor. There is a file ?testmethods.txt? in condor_tests that explains what many of the tests do.
+test suite are designed to test the remote system calls or checkpointing of HTCondor. There is a file ?testmethods.txt? in condor_tests that explains what many of the tests do.
-Standard Universe compiler directory highlights: syscall_tester calls a number of generic POSIX functions with both valid and invalid arguments, and makes sure that it gets sane answers back. It's designed to test the Condor syscall library. floats does some floating point calculations, forces itself to checkpoint, and outputs the state of the floating point registers after the checkpoint, to ensure that we can safely checkpoint floating point registers. Most of the top level tests check other aspects of Condor?s behavior and are named to point at what they are testing.
+Standard Universe compiler directory highlights: syscall_tester calls a number of generic POSIX functions with both valid and invalid arguments, and makes sure that it gets sane answers back. It's designed to test the HTCondor syscall library. floats does some floating point calculations, forces itself to checkpoint, and outputs the state of the floating point registers after the checkpoint, to ensure that we can safely checkpoint floating point registers. Most of the top level tests check other aspects of HTCondor?s behavior and are named to point at what they are testing.
There are very few restrictions on what your program has to do or how it has to be written. It's polite to have it run in a fairly short period, and to be
-deterministic. If you are going to use the standard universe, you should be aware of the ckpt_and_exit() call - you can directly force your program to save its state and exit. If your program is running under Condor, it will go back into the queue and be resubmitted, and it will be restarted as though it had just returned from the ckpt_and_exit() call.
+deterministic. If you are going to use the standard universe, you should be aware of the ckpt_and_exit() call - you can directly force your program to save its state and exit. If your program is running under HTCondor, it will go back into the queue and be resubmitted, and it will be restarted as though it had just returned from the ckpt_and_exit() call.
Once you've written your program, you have to decide how it is built and where to place it. Most non-Standard Universe tests get added to Imakefile. Standard
Universe tests get added to the CImakefile, CPPImakefile and FImakefile - in the
@@ -180,17 +180,17 @@
BUILD( $(CC), <testname>, c )
That rule will build testname (which ends in .c) for every compiler on that
-platform (usually the vendor C C++ compilers, and the GNU C and C++ compilers) It will build two versions of your program for each compiler - a testname.remote and a testname.vanilla, which are standard and vanilla universe jobs, respectively. It will also by default place a symlink to the .run file for that test, and the .cmd file that is used to submit that job to Condor. If you specifically know that your test will not run under the standard universe, you can build it with BUILD_SPECIFIC_VANILLA, which will not try and relink it with the syscall library.
+platform (usually the vendor C C++ compilers, and the GNU C and C++ compilers) It will build two versions of your program for each compiler - a testname.remote and a testname.vanilla, which are standard and vanilla universe jobs, respectively. It will also by default place a symlink to the .run file for that test, and the .cmd file that is used to submit that job to HTCondor. If you specifically know that your test will not run under the standard universe, you can build it with BUILD_SPECIFIC_VANILLA, which will not try and relink it with the syscall library.
If your test program is a Perl script, or something that does not need to be
"built", you can use all_symlink_target() to get it represented into the compiler subdirectories so batch_test.pl will run it.
Now that you've got your test program represented with a binary and a .run file,
-it's time to run your test. The first thing to remember is that the .run file is a perl script. It's responsible for running your test and deciding if it passed or failed - it technically does not have to use Condor for any of that, and we could put unit tests into batch_test.pl that simply run. The only strange thing is that they some have to appear in a "compiler" subdirectory. However, nearly all tests are going to be run as Condor jobs (which is why the default BUILD rule symlinks a <testname>.cmd file for you in the compiler subdirectory).
+it's time to run your test. The first thing to remember is that the .run file is a perl script. It's responsible for running your test and deciding if it passed or failed - it technically does not have to use HTCondor for any of that, and we could put unit tests into batch_test.pl that simply run. The only strange thing is that they some have to appear in a "compiler" subdirectory. However, nearly all tests are going to be run as HTCondor jobs (which is why the default BUILD rule symlinks a <testname>.cmd file for you in the compiler subdirectory).
-Because most of the tests are going to be submitting and running Condor jobs, they generally use the CondorTest.pm Perl module. The CondorTest perl module in turn builds on the Condor.pm perl module. The Condor.pm module provides a a Perl
-interface to submitting Condor jobs and receiving callbacks when events happen. (It monitors the UserLog file the job submit file specifies to discover this
-information.) CondorTest.pm adds several new functions on top of Condor.pm, mostly for managing expected output. Again, a .run file is just a Perl script, and as such does not have to use the Condor perl modules or even use Condor at all.
+Because most of the tests are going to be submitting and running HTCondor jobs, they generally use the CondorTest.pm Perl module. The CondorTest perl module in turn builds on the Condor.pm perl module. The Condor.pm module provides a a Perl
+interface to submitting HTCondor jobs and receiving callbacks when events happen. (It monitors the UserLog file the job submit file specifies to discover this
+information.) CondorTest.pm adds several new functions on top of Condor.pm, mostly for managing expected output. Again, a .run file is just a Perl script, and as such does not have to use the HTCondor perl modules or even use HTCondor at all.
**Sample Test**
@@ -230,7 +230,7 @@
means don't look at lines 4, 5, and 6.
-CondorTest::RegisterExitedSuccess means to "Call this function Condor says the job has exited and left the queue." The CondorTest::DefaultOutputTest is a predefined function that compares the text from expected_output_array to the stdout that your job produced and ensures that they're the same. It will also complain if there is data in the stderr file. Your test is free to define it's own function to be called - on tests that don't care to check the output, a common trick is to say:
+CondorTest::RegisterExitedSuccess means to "Call this function HTCondor says the job has exited and left the queue." The CondorTest::DefaultOutputTest is a predefined function that compares the text from expected_output_array to the stdout that your job produced and ensures that they're the same. It will also complain if there is data in the stderr file. Your test is free to define it's own function to be called - on tests that don't care to check the output, a common trick is to say:
CondorTest::RegisterExitedSuccess( $testname, sub { return 1 } );
@@ -239,7 +239,7 @@
coredump.run for an example. There are also other callbacks that are available
through the CondorTest interface - see the source for CondorTest.pm and look in the function RunTest to see what all you can register.
-CondorTest::RunTest ultimately submits the job to Condor, and blocks until the job has left the queue. The arguments are the name of the test, the submit file to use, and whether or not Condor should try and force a checkpoint. If you can't use ckpt_and_exit, but you need to checkpoint for your test to be valid, set this flag to be 1. However, realize that your job will need to run for "long enough" to make sure that:
+CondorTest::RunTest ultimately submits the job to HTCondor, and blocks until the job has left the queue. The arguments are the name of the test, the submit file to use, and whether or not HTCondor should try and force a checkpoint. If you can't use ckpt_and_exit, but you need to checkpoint for your test to be valid, set this flag to be 1. However, realize that your job will need to run for "long enough" to make sure that:
1: The Condor.pm module sees that your job is executing
2: It has a chance to send the 'condor_vacate' to the remote machine
@@ -253,18 +253,18 @@
**Added tidbits:**
There are many examples to look at in src/condor_tests/Imakefile. We also have a
-perl module called CondorPersonal.pm which allows us to setup tests which require a modified environment so as to not change the environment of the personal condor running all of the tests. It allows us to emulate most pool configurations. Look at the job_flocking_to, job_condorc_ab_van and cmd_status_shows-avail for more complicated examples.
+perl module called CondorPersonal.pm which allows us to setup tests which require a modified environment so as to not change the environment of the personal HTCondor running all of the tests. It allows us to emulate most pool configurations. Look at the job_flocking_to, job_condorc_ab_van and cmd_status_shows-avail for more complicated examples.
**Setting up for testing on windows**
*: Install windows msi
-*: Add path to condor binaries(bin and sbin) to PATH env variable
+*: Add path to HTCondor binaries(bin and sbin) to PATH env variable
*: Install cygwin with cygwin perl
*: Install Active perl
*: Bring down sources for condor_examples, condor_scripts and condor_tests to c:\
*: Cp *.pm and batch_test.pl from condor_scripts to condor_tests
*: Cd to condor_tests
-*: If you are using a personal Condor in your path, then =chmod go+rX <bindir>= so perl's -x works like how you expect.
+*: If you are using a personal HTCondor in your path, then =chmod go+rX <bindir>= so perl's -x works like how you expect.
*: ./batch_test.pl -d . -b
**Controlling Windows Testing**
