Any developer, who implements a major new feature, should write a regression test that exercises and validates the new feature. Each regression test is a complete test by itself. It terminates any running Bacula, initializes the database, starts Bacula, then runs the test by using the console program.
You can run any individual test by hand by cd'ing to the regress directory and entering:
The directory structure of the regression tests is:
regress - Makefile, scripts to start tests |------ scripts - Scripts and conf files |-------tests - All test scripts are here | |------------------ -- All directories below this point are used | for testing, but are created from the | above directories and are removed with | "make distclean" | |------ bin - This is the install directory for | Bacula to be used testing |------ build - Where the Bacula source build tree is |------ tmp - Most temp files go here |------ working - Bacula working directory |------ weird-files - Weird files used in two of the tests.
If you want to write a new regression test, it is best to start with one of the existing test scripts, and modify it to do the new test.
When adding a new test, be extremely careful about adding anything to any of the daemons' configuration files. The reason is that it may change the prompts that are sent to the console. For example, adding a Pool means that the current scripts, which assume that Bacula automatically selects a Pool, will now be presented with a new prompt, so the test will fail. If you need to enhance the configuration files, consider making your own versions.
REGRESS_WAIT=1 export REGRESS_WAIT
Then executing the script. When the script prints the following line:
Start Bacula under debugger and enter anything when ready ...
You start the Bacula component you want to run under the debugger in a different shell window. For example:
cd .../regress/bin gdb bacula-sd (possibly set breakpoints, ...) run -s -f
Then enter any character in the window with the above message. An error message will appear saying that the daemon you are debugging is already running, which is the case. You can simply ignore the error message.
Kern Sibbald 2010-08-30