tests: Update README files and add new README files where missing

Signed-off-by: Martin Schwenke <martin@meltin.net>

(This used to be ctdb commit bef03b32f8ec114a64c55b25951aeeb939d87b33)

1 files changed, 58 insertions, 77 deletions

diff --git a/ctdb/tests/README b/ctdb/tests/README
index 5b6b714560f..87c7db397e0 100644
--- a/ctdb/tests/README
+++ b/ctdb/tests/README
@@ -1,106 +1,87 @@
 Introduction
 ------------
 
-The run_tests script can be run as follows:
+For a developer, the simplest way of running most tests on a local
+machine from within the git repository is:
 
-  scripts/run_tests simple/*.sh
+  make test
 
-It can also be run from other places (e.g. the top level ctdb source
-directory), as it works out where the tree is.
+This runs all unit tests (onnode, takeover, tool, eventscripts) and
+the tests against local daemons (simple) using the script
+tests/run_tests.sh.
 
-The pseudo-test simple/00_ctdb_init.sh causes ctdb to be (re)started
-on all nodes to attempt to force the cluster into a healthy state.  By
-default (i.e. if CTDB_TEST_REAL_CLUSTER is unset - see below) this
-causes some local daemons to be started on the local machine.  Tests
-can also be run against a real or virtual cluster.  All tests
-communicate with cluster nodes using onnode - when using local daemons
-this is accomplished via some test hooks in onnode and the ctdb
-client.
+When running tests against a real or virtual cluster the script
+tests/run_cluster_tests.sh can be used.  This runs all integration
+tests (simple, complex).
 
-Command-line options
---------------------
+Both of these scripts can also take a list of tests to run.
 
-The most useful option is "-s", which causes a summary of test results
-to be printed at the end of testing.
+scripts/run_tests
+-----------------
 
-Environment variables
----------------------
+The above scripts invoke tests/scripts/run_tests.  This script has a
+lot of command-line switches.  Some of the more useful options
+include:
 
-run_tests supports several environment variables, mostly implemented
-in scripts/ctdb_test_env.  These are:
+  -s  Print a summary of tests results after running all tests
 
-* CTDB_TEST_REAL_CLUSTER
+  -l  Use local daemons for integration tests
 
-  If set, testing will occur on a real or virtual cluster.
+      This allows the tests in "simple" to be run against local
+      daemons.
 
-  Assumptions:
+      All integration tests communicate with cluster nodes using
+      onnode or the ctdb tool, which both have some test hooks to
+      support local daemons.
 
-  - The ctdb client command can be found via $PATH on the nodes.
+      By default 3 daemons are used.  If you want to use a different
+      number of daemons then do not use this option but set
+      TEST_LOCAL_DAEMONS to the desired number of daemons instead.
+      The -l option just sets TEST_LOCAL_DAEMONS to 3...  :-)
 
-  - Password-less ssh access to the cluster nodes is permitted from
-    the test host.
+  -e  Exit on the first test failure
 
-  - $CTDB_NODES_FILE is set to the location of a file similar to
-    /etc/ctdb/nodes.  The file can be obtained by scping it from one
-    of the cluster nodes.
+  -H  No headers - for running single test with other wrapper
 
-  - See CTDB_TEST_REMOTE_DIR.
+      This allows tests to be embedded in some other test framework
+      and executed one-by-one with all the required
+      environment/infrastructure.
 
-  If not set, testing will proceed against local daemons.
+      This replaces the old ctdb_test_env script.
 
-* CTDB_TEST_REMOTE_DIR
+How do the tests find remote test programs?
+-------------------------------------------
 
-  This may be required when running against a real or virtual cluster
-  (as opposed to local daemons).
+If the all of the cluster nodes have the CTDB git tree in the same
+location as on the test client then no special action is necessary.
+The simplest way of doing this is to share the tree to cluster nodes
+and test clients via NFS.
 
-  If set, this points to a directory containing the contents of the
-  tests/scripts/ directory, as well as all of the test binaries.  This
-  can be accomplished in a couple of ways:
+If cluster nodes do not have the CTDB git tree then
+CTDB_TEST_REMOTE_DIR can be set to a directory that, on each cluster
+node, contains the contents of tests/scripts/ and tests/bin/.
 
-  * By copying the relevant scripts/binaries to some directory.
+In the future this will hopefully (also) be supported via a ctdb-test
+package.
 
-  * Building an RPM containing all of the test code that is required
-    on the cluster nodes and installing it on each node.  Hopefully
-    this will be supported in a future version of the CTDB packaging
-    process.
+Running the ctdb tool under valgrind
+------------------------------------
 
-  If not set, the test system assumes that the CTDB tree is available
-  in the same location on the cluster nodes as on the test host.  This
-  could be accomplished by copying or by sharing with NFS (or
-  similar).
+The easiest way of doing this is something like:
 
-* VALGRIND
+  VALGRIND="valgrind -q" scripts/run_tests ...
 
-  This can be used to cause all invocations of the ctdb client (and,
-  with local daemons, the ctdbd daemons themselves) to occur under
-  valgrind.
+This can be used to cause all invocations of the ctdb client (and,
+with local daemons, the ctdbd daemons themselves) to occur under
+valgrind.
 
-  The easiest way of doing this is something like:
+NOTE: Some libc calls seem to do weird things and perhaps cause
+spurious output from ctdbd at start time.  Please read valgrind output
+carefully before reporting bugs.  :-)
 
-    VALGRIND="valgrind -q" scripts/run_tests ...
+How is the ctdb tool invoked?
+-----------------------------
 
-  NOTE: Some libc calls seem to do weird things and perhaps cause
-  spurious output from ctdbd at start time.  Please read valgrind
-  output carefully before reporting bugs.  :-)
-
-* CTDB
-
-  How to invoke the ctdb client.  If not already set and if $VALGRIND
-  is set, this is set to "$VALGRIND ctdb".  If this is not already set
-  but $VALGRIND is not set, this is simply set to "ctdb"
-
-Look, no run_test!
-------------------
-
-If you want to integrate individual tests into some other test
-environment you can use scripts/ctdb_test_env to wrap individual
-tests.  They will return 0 on success, non-zero otherwise, and will
-print the output omitting the test header/footer that surrounds test
-output when tests are run using run_tests.  So, you can do something
-like:
-
-  for i in simple/*.sh ; do
-      my_test_framework_wrapper scripts/ctdb_test_env $i
-  done
-
-to have your own framework process the test results and output.
+$CTDB determines how to invoke the ctdb client.  If not already set
+and if $VALGRIND is set, this is set to "$VALGRIND ctdb".  If this is
+not already set but $VALGRIND is not set, this is simply set to "ctdb"