summaryrefslogtreecommitdiffstats
path: root/bin/tests/system/README
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--bin/tests/system/README773
1 files changed, 773 insertions, 0 deletions
diff --git a/bin/tests/system/README b/bin/tests/system/README
new file mode 100644
index 0000000..f527e79
--- /dev/null
+++ b/bin/tests/system/README
@@ -0,0 +1,773 @@
+Copyright (C) Internet Systems Consortium, Inc. ("ISC")
+
+See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
+
+Introduction
+===
+This directory holds a simple test environment for running bind9 system tests
+involving multiple name servers.
+
+With the exception of "common" (which holds configuration information common to
+multiple tests) and "win32" (which holds files needed to run the tests in a
+Windows environment), each directory holds a set of scripts and configuration
+files to test different parts of BIND. The directories are named for the
+aspect of BIND they test, for example:
+
+ dnssec/ DNSSEC tests
+ forward/ Forwarding tests
+ glue/ Glue handling tests
+
+etc.
+
+Typically each set of tests sets up 2-5 name servers and then performs one or
+more tests against them. Within the test subdirectory, each name server has a
+separate subdirectory containing its configuration data. These subdirectories
+are named "nsN" or "ansN" (where N is a number between 1 and 8, e.g. ns1, ans2
+etc.)
+
+The tests are completely self-contained and do not require access to the real
+DNS. Generally, one of the test servers (usually ns1) is set up as a root
+nameserver and is listed in the hints file of the others.
+
+
+Preparing to Run the Tests
+===
+To enable all servers to run on the same machine, they bind to separate virtual
+IP addresses on the loopback interface. ns1 runs on 10.53.0.1, ns2 on
+10.53.0.2, etc. Before running any tests, you must set up these addresses by
+running the command
+
+ sh ifconfig.sh up
+
+as root. The interfaces can be removed by executing the command:
+
+ sh ifconfig.sh down
+
+... also as root.
+
+The servers use unprivileged ports (above 1024) instead of the usual port 53,
+so they can be run without root privileges once the interfaces have been set
+up.
+
+
+Note for MacOS Users
+---
+If you wish to make the interfaces survive across reboots, copy
+org.isc.bind.system and org.isc.bind.system.plist to /Library/LaunchDaemons
+then run
+
+ launchctl load /Library/LaunchDaemons/org.isc.bind.system.plist
+
+... as root.
+
+
+Running the System Tests
+===
+
+Running an Individual Test
+---
+The tests can be run individually using the following command:
+
+ sh run.sh [flags] <test-name> [<test-arguments>]
+
+e.g.
+
+ sh run.sh [flags] notify
+
+Optional flags are:
+
+ -k Keep servers running after the test completes. Each test
+ usually starts a number of nameservers, either instances
+ of the "named" being tested, or custom servers (written in
+ Python or Perl) that feature test-specific behavior. The
+ servers are automatically started before the test is run
+ and stopped after it ends. This flag leaves them running
+ at the end of the test, so that additional queries can be
+ sent by hand. To stop the servers afterwards, use the
+ command "sh stop.sh <test-name>".
+
+ -n Noclean - do not remove the output files if the test
+ completes successfully. By default, files created by the
+ test are deleted if it passes; they are not deleted if the
+ test fails.
+
+ -p <number> Sets the range of ports used by the test. A block of 100
+ ports is available for each test, the number given to the
+ "-p" switch being the number of the start of that block
+ (e.g. "-p 7900" will mean that the test is able to use
+ ports 7900 through 7999). If not specified, the test will
+ have ports 5000 to 5099 available to it.
+
+ -r The "runall" flag. This is related to cleaning up after
+ the tests (see "Maintenance Notes" below). If specified,
+ it prevents a copy of the test's output listing from being
+ deleted when the directory is cleaned up after the test
+ completes. (The test's output listing comprises messages
+ produced by the test during its execution; it does not
+ include the output files produced by utilities such as
+ "dig" or "rndc", nor any logging output from named itself.)
+ It is usually only used when "run.sh" is being called
+ during a run of the entire test suite. Note that if "-n"
+ is specified on the "run.sh" command line, the test output
+ is retained even if this option is omitted.
+
+Arguments are:
+
+ test-name Mandatory. The name of the test, which is the name of the
+ subdirectory in bin/tests/system holding the test files.
+
+ test-arguments Optional arguments that are passed to each of the test's
+ scripts.
+
+
+Running All The System Tests
+---
+To run all the system tests, enter the command:
+
+ sh runall.sh [-c] [-n] [numproc]
+
+The optional flag "-c" forces colored output (by default system test output is
+not printed in color due to run.sh being piped through "tee").
+
+The optional flag "-n" has the same effect as it does for "run.sh" - it causes
+the retention of all output files from all tests.
+
+The optional "numproc" argument specifies the maximum number of tests that can
+run in parallel. The default is 1, which means that all of the tests run
+sequentially. If greater than 1, up to "numproc" tests will run simultaneously,
+new tests being started as tests finish. Each test will get a unique set of
+ports, so there is no danger of tests interfering with one another. Parallel
+running will reduce the total time taken to run the BIND system tests, but will
+mean that the output from all the tests sent to the screen will be mixed up
+with one another. However, the systests.output file produced at the end of the
+run (in the bin/tests/system directory) will contain the output from each test
+in sequential order.
+
+Note that it is not possible to pass arguments to tests though the "runall.sh"
+script.
+
+A run of all the system tests can also be initiated via make:
+
+ make [-j numproc] test
+
+In this case, retention of the output files after a test completes successfully
+is specified by setting the environment variable SYSTEMTEST_NO_CLEAN to 1 prior
+to running make, e.g.
+
+ SYSTEMTEST_NO_CLEAN=1 make [-j numproc] test
+
+while setting environment variable SYSTEMTEST_FORCE_COLOR to 1 forces system
+test output to be printed in color.
+
+
+Running Multiple System Test Suites Simultaneously
+---
+In some cases it may be desirable to have multiple instances of the system test
+suite running simultaneously (e.g. from different terminal windows). To do
+this:
+
+1. Each installation must have its own directory tree. The system tests create
+files in the test directories, so separate directory trees are required to
+avoid interference between the same test running in the different
+installations.
+
+2. For one of the test suites, the starting port number must be specified by
+setting the environment variable STARTPORT before starting the test suite.
+Each test suite comprises about 100 tests, each being allocated a set of 100
+ports. The port ranges for each test are allocated sequentially, so each test
+suite requires about 10,000 ports to itself. By default, the port allocation
+starts at 5,000. So the following set of commands:
+
+ Terminal Window 1:
+ cd <installation-1>/bin/tests/system
+ sh runall.sh 4
+
+ Terminal Window 2:
+ cd <installation-2>/bin/tests/system
+ STARTPORT=20000 sh runall.sh 4
+
+... will start the test suite for installation-1 using the default base port
+of 5,000, so the test suite will use ports 5,000 through 15,000 (or there
+abouts). The use of "STARTPORT=20000" to prefix the run of the test suite for
+installation-2 will mean the test suite uses ports 20,000 through 30,000 or so.
+
+
+Format of Test Output
+---
+All output from the system tests is in the form of lines with the following
+structure:
+
+ <letter>:<test-name>:<message> [(<number>)]
+
+e.g.
+
+ I:catz:checking that dom1.example is not served by master (1)
+
+The meanings of the fields are as follows:
+
+<letter>
+This indicates the type of message. This is one of:
+
+ S Start of the test
+ A Start of test (retained for backwards compatibility)
+ T Start of test (retained for backwards compatibility)
+ E End of the test
+ I Information. A test will typically output many of these messages
+ during its run, indicating test progress. Note that such a message may
+ be of the form "I:testname:failed", indicating that a sub-test has
+ failed.
+ R Result. Each test will result in one such message, which is of the
+ form:
+
+ R:<test-name>:<result>
+
+ where <result> is one of:
+
+ PASS The test passed
+ FAIL The test failed
+ SKIPPED The test was not run, usually because some
+ prerequisites required to run the test are missing.
+ UNTESTED The test was not run for some other reason, e.g. a
+ prerequisite is available but is not compatible with
+ the platform on which the test is run.
+
+<test-name>
+This is the name of the test from which the message emanated, which is also the
+name of the subdirectory holding the test files.
+
+<message>
+This is text output by the test during its execution.
+
+(<number>)
+If present, this will correlate with a file created by the test. The tests
+execute commands and route the output of each command to a file. The name of
+this file depends on the command and the test, but will usually be of the form:
+
+ <command>.out.<suffix><number>
+
+e.g. nsupdate.out.test28, dig.out.q3. This aids diagnosis of problems by
+allowing the output that caused the problem message to be identified.
+
+
+Re-Running the Tests
+---
+If there is a requirement to re-run a test (or the entire test suite), the
+files produced by the tests should be deleted first. Normally, these files are
+deleted if the test succeeds but are retained on error.
+
+Deletion of files produced by an individual test can be done with the command:
+
+ sh clean.sh [-r] <test-name>
+
+The optional flag is:
+
+ -r The "runall" flag. This is related to cleaning up after
+ the tests (see "Maintenance Notes" below). If specified,
+ it prevents a copy of the test's output listing from being
+ deleted when the directory is cleaned after the test
+ completes.
+
+Deletion of the files produced by the set of tests (e.g. after the execution
+of "runall.sh") can be deleted by the command:
+
+ sh cleanall.sh
+
+or
+
+ make testclean
+
+(Note that the Makefile has two other targets for cleaning up files: "clean"
+will delete all the files produced by the tests, as well as the object and
+executable files used by the tests. "distclean" does all the work of "clean"
+as well as deleting configuration files produced by "configure".)
+
+
+Developer Notes
+===
+This section is intended for developers writing new tests.
+
+
+Overview
+---
+As noted above, each test is in a separate directory. To interact with the
+test framework, the directories contain the following standard files:
+
+prereq.sh Run at the beginning to determine whether the test can be run at
+ all; if not, we see a result of R:SKIPPED or R:UNTESTED. This file
+ is optional: if not present, the test is assumed to have all its
+ prerequisites met.
+
+setup.sh Run after prereq.sh, this sets up the preconditions for the tests.
+ Although optional, virtually all tests will require such a file to
+ set up the ports they should use for the test.
+
+tests.sh Runs the actual tests. This file is mandatory.
+
+clean.sh Run at the end to clean up temporary files, but only if the test
+ was completed successfully and its running was not inhibited by the
+ "-n" switch being passed to "run.sh". Otherwise the temporary
+ files are left in place for inspection.
+
+ns<N> These subdirectories contain test name servers that can be queried
+ or can interact with each other. The value of N indicates the
+ address the server listens on: for example, ns2 listens on
+ 10.53.0.2, and ns4 on 10.53.0.4. All test servers use an
+ unprivileged port, so they don't need to run as root. These
+ servers log at the highest debug level and the log is captured in
+ the file "named.run".
+
+ans<N> Like ns[X], but these are simple mock name servers implemented in
+ Perl or Python. They are generally programmed to misbehave in ways
+ named would not so as to exercise named's ability to interoperate
+ with badly behaved name servers.
+
+
+Port Usage
+---
+In order for the tests to run in parallel, each test requires a unique set of
+ports. These are specified by the "-p" option passed to "run.sh", which sets
+environment variables that the scripts listed above can reference.
+
+The convention used in the system tests is that the number passed is the start
+of a range of 100 ports. The test is free to use the ports as required,
+although the first ten ports in the block are named and generally tests use the
+named ports for their intended purpose. The names of the environment variables
+are:
+
+ PORT Number to be used for the query port.
+ CONTROLPORT Number to be used as the RNDC control port.
+ EXTRAPORT1 - EXTRAPORT8 Eight port numbers that can be used as needed.
+
+Two other environment variables are defined:
+
+ LOWPORT The lowest port number in the range.
+ HIGHPORT The highest port number in the range.
+
+Since port ranges usually start on a boundary of 10, the variables are set such
+that the last digit of the port number corresponds to the number of the
+EXTRAPORTn variable. For example, if the port range were to start at 5200, the
+port assignments would be:
+
+ PORT = 5200
+ EXTRAPORT1 = 5201
+ :
+ EXTRAPORT8 = 5208
+ CONTROLPORT = 5209
+ LOWPORT = 5200
+ HIGHPORT = 5299
+
+When running tests in parallel (i.e. giving a value of "numproc" greater than 1
+in the "make" or "runall.sh" commands listed above), it is guaranteed that each
+test will get a set of unique port numbers.
+
+
+Writing a Test
+---
+The test framework requires up to four shell scripts (listed above) as well as
+a number of nameserver instances to run. Certain expectations are put on each
+script:
+
+
+General
+---
+1. Each of the four scripts will be invoked with the command
+
+ (cd <test-directory> ; sh <script> [<arguments>] )
+
+... so that working directory when the script starts executing is the test
+directory.
+
+2. Arguments can be only passed to the script if the test is being run as a
+one-off with "run.sh". In this case, everything on the command line after the
+name of the test is passed to each script. For example, the command:
+
+ sh run.sh -p 12300 mytest -D xyz
+
+... will run "mytest" with a port range of 12300 to 12399. Each of the
+framework scripts provided by the test will be invoked using the remaining
+arguments, e.g.:
+
+ (cd mytest ; sh prereq.sh -D xyz)
+ (cd mytest ; sh setup.sh -D xyz)
+ (cd mytest ; sh tests.sh -D xyz)
+ (cd mytest ; sh clean.sh -D xyz)
+
+No arguments will be passed to the test scripts if the test is run as part of
+a run of the full test suite (e.g. the tests are started with "runall.sh").
+
+3. Each script should start with the following lines:
+
+ SYSTEMTESTTOP=..
+ . $SYSTEMTESTTOP/conf.sh
+
+"conf.sh" defines a series of environment variables together with functions
+useful for the test scripts. (conf.sh.win32 is the Windows equivalent of this
+file.)
+
+
+prereq.sh
+---
+As noted above, this is optional. If present, it should check whether specific
+software needed to run the test is available and/or whether BIND has been
+configured with the appropriate options required.
+
+ * If the software required to run the test is present and the BIND
+ configure options are correct, prereq.sh should return with a status code
+ of 0.
+
+ * If the software required to run the test is not available and/or BIND
+ has not been configured with the appropriate options, prereq.sh should
+ return with a status code of 1.
+
+ * If there is some other problem (e.g. prerequisite software is available
+ but is not properly configured), a status code of 255 should be returned.
+
+
+setup.sh
+---
+This is responsible for setting up the configuration files used in the test.
+
+To cope with the varying port number, ports are not hard-coded into
+configuration files (or, for that matter, scripts that emulate nameservers).
+Instead, setup.sh is responsible for editing the configuration files to set the
+port numbers.
+
+To do this, configuration files should be supplied in the form of templates
+containing tokens identifying ports. The tokens have the same name as the
+environment variables listed above, but are prefixed and suffixed by the "@"
+symbol. For example, a fragment of a configuration file template might look
+like:
+
+ controls {
+ inet 10.53.0.1 port @CONTROLPORT@ allow { any; } keys { rndc_key; };
+ };
+
+ options {
+ query-source address 10.53.0.1;
+ notify-source 10.53.0.1;
+ transfer-source 10.53.0.1;
+ port @PORT@;
+ allow-new-zones yes;
+ };
+
+setup.sh should copy the template to the desired filename using the
+"copy_setports" shell function defined in "conf.sh", i.e.
+
+ copy_setports ns1/named.conf.in ns1/named.conf
+
+This replaces the tokens @PORT@, @CONTROLPORT@, @EXTRAPORT1@ through
+@EXTRAPORT8@ with the contents of the environment variables listed above.
+setup.sh should do this for all configuration files required when the test
+starts.
+
+("setup.sh" should also use this method for replacing the tokens in any Perl or
+Python name servers used in the test.)
+
+
+tests.sh
+---
+This is the main test file and the contents depend on the test. The contents
+are completely up to the developer, although most test scripts have a form
+similar to the following for each sub-test:
+
+ 1. n=`expr $n + 1`
+ 2. echo_i "prime cache nodata.example ($n)"
+ 3. ret=0
+ 4. $DIG -p ${PORT} @10.53.0.1 nodata.example TXT > dig.out.test$n
+ 5. grep "status: NOERROR" dig.out.test$n > /dev/null || ret=1
+ 6. grep "ANSWER: 0," dig.out.test$n > /dev/null || ret=1
+ 7. if [ $ret != 0 ]; then echo_i "failed"; fi
+ 8. status=`expr $status + $ret`
+
+1. Increment the test number "n" (initialized to zero at the start of the
+ script).
+
+2. Indicate that the sub-test is about to begin. Note that "echo_i" instead
+ of "echo" is used. echo_i is a function defined in "conf.sh" which will
+ prefix the message with "I:<testname>:", so allowing the output from each
+ test to be identified within the output. The test number is included in
+ the message in order to tie the sub-test with its output.
+
+3. Initialize return status.
+
+4 - 6. Carry out the sub-test. In this case, a nameserver is queried (note
+ that the port used is given by the PORT environment variable, which was set
+ by the inclusion of the file "conf.sh" at the start of the script). The
+ output is routed to a file whose suffix includes the test number. The
+ response from the server is examined and, in this case, if the required
+ string is not found, an error is indicated by setting "ret" to 1.
+
+7. If the sub-test failed, a message is printed. "echo_i" is used to print
+ the message to add the prefix "I:<test-name>:" before it is output.
+
+8. "status", used to track how many of the sub-tests have failed, is
+ incremented accordingly. The value of "status" determines the status
+ returned by "tests.sh", which in turn determines whether the framework
+ prints the PASS or FAIL message.
+
+Regardless of this, rules that should be followed are:
+
+a. Use the environment variables set by conf.sh to determine the ports to use
+ for sending and receiving queries.
+
+b. Use a counter to tag messages and to associate the messages with the output
+ files.
+
+c. Store all output produced by queries/commands into files. These files
+ should be named according to the command that produced them, e.g. "dig"
+ output should be stored in a file "dig.out.<suffix>", the suffix being
+ related to the value of the counter.
+
+d. Use "echo_i" to output informational messages.
+
+e. Retain a count of test failures and return this as the exit status from
+ the script.
+
+
+clean.sh
+---
+The inverse of "setup.sh", this is invoked by the framework to clean up the
+test directory. It should delete all files that have been created by the test
+during its run.
+
+
+Starting Nameservers
+---
+As noted earlier, a system test will involve a number of nameservers. These
+will be either instances of named, or special servers written in a language
+such as Perl or Python.
+
+For the former, the version of "named" being run is that in the "bin/named"
+directory in the tree holding the tests (i.e. if "make test" is being run
+immediately after "make", the version of "named" used is that just built). The
+configuration files, zone files etc. for these servers are located in
+subdirectories of the test directory named "nsN", where N is a small integer.
+The latter are special nameservers, mostly used for generating deliberately bad
+responses, located in subdirectories named "ansN" (again, N is an integer).
+In addition to configuration files, these directories should hold the
+appropriate script files as well.
+
+Note that the "N" for a particular test forms a single number space, e.g. if
+there is an "ns2" directory, there cannot be an "ans2" directory as well.
+Ideally, the directory numbers should start at 1 and work upwards.
+
+When running a test, the servers are started using "start.sh" (which is nothing
+more than a wrapper for start.pl). The options for "start.pl" are documented
+in the header for that file, so will not be repeated here. In summary, when
+invoked by "run.sh", start.pl looks for directories named "nsN" or "ansN" in
+the test directory and starts the servers it finds there.
+
+
+"named" Command-Line Options
+---
+By default, start.pl starts a "named" server with the following options:
+
+ -c named.conf Specifies the configuration file to use (so by implication,
+ each "nsN" nameserver's configuration file must be called
+ named.conf).
+
+ -d 99 Sets the maximum debugging level.
+
+ -D <name> The "-D" option sets a string used to identify the
+ nameserver in a process listing. In this case, the string
+ is the name of the subdirectory.
+
+ -g Runs the server in the foreground and logs everything to
+ stderr.
+
+ -m record,size,mctx
+ Turns on these memory usage debugging flags.
+
+ -U 4 Uses four listeners.
+
+ -X named.lock Acquires a lock on this file in the "nsN" directory, so
+ preventing multiple instances of this named running in this
+ directory (which could possibly interfere with the test).
+
+In addition, start.pl also sets the following undocumented flag:
+
+ -T clienttest Makes clients single-shot with their own memory context.
+
+All output is sent to a file called "named.run" in the nameserver directory.
+
+The options used to start named can be altered. There are three ways of doing
+this. "start.pl" checks the methods in a specific order: if a check succeeds,
+the options are set and any other specification is ignored. In order, these
+are:
+
+1. Specifying options to "start.sh"/"start.pl" after the name of the test
+directory, e.g.
+
+ sh start.sh reclimit ns1 -- "-c n.conf -d 43"
+
+(This is only really useful when running tests interactively.)
+
+2. Including a file called "named.args" in the "nsN" directory. If present,
+the contents of the first non-commented, non-blank line of the file are used as
+the named command-line arguments. The rest of the file is ignored.
+
+3. Tweaking the default command line arguments with "-T" options. This flag is
+used to alter the behavior of BIND for testing and is not documented in the
+ARM. The "clienttest" option has already been mentioned, but the presence of
+certain files in the "nsN" directory adds flags to the default command line
+(the content of the files is irrelevant - it is only the presence that counts):
+
+ named.noaa Appends "-T noaa" to the command line, which causes
+ "named" to never set the AA bit in an answer.
+
+ named.dropedns Adds "-T dropedns" to the command line, which causes
+ "named" to recognise EDNS options in messages, but drop
+ messages containing them.
+
+ named.maxudp1460 Adds "-T maxudp1460" to the command line, setting the
+ maximum UDP size handled by named to 1460.
+
+ named.maxudp512 Adds "-T maxudp512" to the command line, setting the
+ maximum UDP size handled by named to 512.
+
+ named.noedns Appends "-T noedns" to the command line, which disables
+ recognition of EDNS options in messages.
+
+ named.notcp Adds "-T notcp", which disables TCP in "named".
+
+ named.soa Appends "-T nosoa" to the command line, which disables
+ the addition of SOA records to negative responses (or to
+ the additional section if the response is triggered by RPZ
+ rewriting).
+
+
+Starting Other Nameservers
+---
+In contrast to "named", nameservers written in Perl or Python (whose script
+file should have the name "ans.pl" or "ans.py" respectively) are started with a
+fixed command line. In essence, the server is given the address and nothing
+else.
+
+(This is not strictly true: Python servers are provided with the number of the
+query port to use. Altering the port used by Perl servers currently requires
+creating a template file containing the "@PORT@" token, and having "setup.sh"
+substitute the actual port being used before the test starts.)
+
+
+Stopping Nameservers
+---
+As might be expected, the test system stops nameservers with the script
+"stop.sh", which is little more than a wrapper for "stop.pl". Like "start.pl",
+the options available are listed in the file's header and will not be repeated
+here.
+
+In summary though, the nameservers for a given test, if left running by
+specifying the "-k" flag to "run.sh" when the test is started, can be stopped
+by the command:
+
+ sh stop.sh <test-name> [server]
+
+... where if the server (e.g. "ns1", "ans3") is not specified, all servers
+associated with the test are stopped.
+
+
+Adding a Test to the System Test Suite
+---
+Once a test has been created, the following files should be edited:
+
+* conf.sh.in The name of the test should be added to the PARALLELDIRS or
+SEQUENTIALDIRS variables as appropriate. The former is used for tests that
+can run in parallel with other tests, the latter for tests that are unable to
+do so.
+
+* conf.sh.win32 This is the Windows equivalent of conf.sh.in. The name of the
+test should be added to the PARALLELDIRS or SEQUENTIALDIRS variables as
+appropriate.
+
+* Makefile.in The name of the test should be added to one of the the PARALLEL
+or SEQUENTIAL variables.
+
+(It is likely that a future iteration of the system test suite will remove the
+need to edit multiple files to add a test.)
+
+
+Valgrind
+---
+When running system tests, named can be run under Valgrind. The output from
+Valgrind are sent to per-process files that can be reviewed after the test has
+completed. To enable this, set the USE_VALGRIND environment variable to
+"helgrind" to run the Helgrind tool, or any other value to run the Memcheck
+tool. To use "helgrind" effectively, build BIND with --disable-atomic.
+
+
+Maintenance Notes
+===
+This section is aimed at developers maintaining BIND's system test framework.
+
+Notes on Parallel Execution
+---
+Although execution of an individual test is controlled by "run.sh", which
+executes the above shell scripts (and starts the relevant servers) for each
+test, the running of all tests in the test suite is controlled by the Makefile.
+("runall.sh" does little more than invoke "make" on the Makefile.)
+
+All system tests are capable of being run in parallel. For this to work, each
+test needs to use a unique set of ports. To avoid the need to define which
+tests use which ports (and so risk port clashes as further tests are added),
+the ports are assigned when the tests are run. This is achieved by having the
+"test" target in the Makefile depend on "parallel.mk". That file is created
+when "make check" is run, and contains a target for each test of the form:
+
+ <test-name>:
+ @$(SHELL) run.sh -r -p <baseport> <test-name>
+
+The <baseport> is unique and the values of <baseport> for each test are
+separated by at least 100 ports.
+
+
+Cleaning Up From Tests
+---
+When a test is run, files are created in the test directory. These files fall
+into three categories:
+
+1. Files generated by the test itself, e.g. output from "dig" and "rndc".
+
+2. Files produced by named which may not be cleaned up if named exits
+abnormally, e.g. core files, PID files etc.
+
+3. The file "test.output" containing the text written to stdout by the test.
+This is only produced when the test is run as part of the entire test suite
+(e.g. via "runall.sh").
+
+If the test fails, all these files are retained. But if the test succeeds,
+they are cleaned up at different times:
+
+1. Files generated by the test itself are cleaned up by the test's own
+"clean.sh". This is called from the system's "clean.sh", which in turn is
+called from "run.sh".
+
+2. Files that may not be cleaned up if named exits abnormally are removed
+by the system's "clean.sh".
+
+3. "test.output" files are deleted when the test suite ends. At this point,
+the file "testsummary.sh" is called which concatenates all the "test.output"
+files into a single "systest.output" file before deleting them.
+
+A complication arises with the "test.output" file however:
+
+1. "clean.sh" is called by "run.sh" if the test ends successfully. For
+this reason, "clean.sh" cannot delete "test.output" as, if the test is
+being run as part of a test suite, the file must be retained.
+
+2. If the deletion of "test.output" were to be solely the responsibility of
+"testsummary.sh", should a test suite terminate abnormally, cleaning up a test
+directory with "sh clean.sh <test-directory>" would leave the file present.
+
+3. An additional step could be added to "cleanall.sh" (which calls the
+system's "clean.sh" for each test) to remove the "test.output" file. However,
+although the file would be deleted should all test directories be cleaned,
+it would still mean that running "clean.sh" on a particular test directory
+could leave the file present.
+
+To get round this, the system's "clean.sh" script takes an optional flag, "-r"
+(the "runall" flag). When the test suite is run, each invocation of "run.sh"
+is passed the runall flag. In turn, "run.sh" passes the flag to "clean.sh",
+which causes that script not to delete the "tests.output" file. In other
+words, when the system's "clean.sh" is invoked standalone on a test directory
+(or as part of a run of "cleanall.sh"), it will delete the "test.output" if it
+is present. When invoked during a run of the entire test suite, it won't.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 13:32:06 +0000