ctdb/tests/README

   1 Introduction
   2 ------------
   3
   4 For a developer, the simplest way of running most tests on a local
   5 machine from within the git repository is:
   6
   7   make test
   8
   9 This runs all unit tests (onnode, takeover, tool, eventscripts) and
  10 the tests against local daemons (simple) using the script
  11 tests/run_tests.sh.
  12
  13 When running tests against a real or virtual cluster the script
  14 tests/run_cluster_tests.sh can be used.  This runs all integration
  15 tests (simple, complex).
  16
  17 Both of these scripts can also take a list of tests to run.  You can
  18 also pass options, which are then passed to run_tests.  However, if
  19 you just try to pass options to run_tests then you lose the default
  20 list of tests that are run.  You can't have everything...
  21
  22 tests/run_tests.sh
  23 ------------------
  24
  25 This script can be used to manually run all or selected unit tests and
  26 simple integration tests against local daemons. Test selection is done
  27 by specifying optional call parameters. If no parameter is given,
  28 all unit tests and simple integration tests are run.
  29
  30 This runs all unit tests of the "tool" category:
  31
  32   ./tests/run_tests.sh tool
  33
  34 In order to run a single test, one simply specifies the path of the
  35 test script to run as the last parameter, e.g.:
  36
  37   ./tests/run_tests.sh ./tests/eventscripts/00.ctdb.monitor.001
  38   ./tests/run_tests.sh ./tests/simple/76_ctdb_pdb_recovery.sh
  39
  40 One can also specify multiple test suites and tests:
  41
  42   ./tests/run_tests.sh eventscripts tool ./tests/onnode/0001.sh
  43
  44 The script also has number of command-line switches.
  45 Some of the more useful options include:
  46
  47   -s  Print a summary of tests results after running all tests
  48
  49   -l  Use local daemons for integration tests
  50
  51       This allows the tests in "simple" to be run against local
  52       daemons.
  53
  54       All integration tests communicate with cluster nodes using
  55       onnode or the ctdb tool, which both have some test hooks to
  56       support local daemons.
  57
  58       By default 3 daemons are used.  If you want to use a different
  59       number of daemons then do not use this option but set
  60       TEST_LOCAL_DAEMONS to the desired number of daemons instead.
  61       The -l option just sets TEST_LOCAL_DAEMONS to 3...  :-)
  62
  63   -e  Exit on the first test failure
  64
  65   -C  Clean up - kill daemons and remove $TEST_VAR_DIR when done
  66
  67       Tests uses a temporary/var directory for test state.  By default,
  68       this directory is not removed when tests are complete, so you
  69       can do forensics or, for integration tests, re-run tests that
  70       have failed against the same directory (with the same local
  71       daemons setup).  So this option cleans things up.
  72
  73       Also kills local daemons associated with directory.
  74
  75   -V  Use <dir> as $TEST_VAR_DIR
  76
  77       Use the specified temporary temporary/var directory.
  78
  79   -H  No headers - for running single test with other wrapper
  80
  81       This allows tests to be embedded in some other test framework
  82       and executed one-by-one with all the required
  83       environment/infrastructure.
  84
  85       This replaces the old ctdb_test_env script.
  86
  87 How do the tests find remote test programs?
  88 -------------------------------------------
  89
  90 If the all of the cluster nodes have the CTDB git tree in the same
  91 location as on the test client then no special action is necessary.
  92 The simplest way of doing this is to share the tree to cluster nodes
  93 and test clients via NFS.
  94
  95 If cluster nodes do not have the CTDB git tree then
  96 CTDB_TEST_REMOTE_DIR can be set to a directory that, on each cluster
  97 node, contains the contents of tests/scripts/ and tests/bin/.
  98
  99 In the future this will hopefully (also) be supported via a ctdb-test
 100 package.
 101
 102 Running the ctdb tool under valgrind
 103 ------------------------------------
 104
 105 The easiest way of doing this is something like:
 106
 107   VALGRIND="valgrind -q" scripts/run_tests ...
 108
 109 This can be used to cause all invocations of the ctdb client (and,
 110 with local daemons, the ctdbd daemons themselves) to occur under
 111 valgrind.
 112
 113 NOTE: Some libc calls seem to do weird things and perhaps cause
 114 spurious output from ctdbd at start time.  Please read valgrind output
 115 carefully before reporting bugs.  :-)
 116
 117 How is the ctdb tool invoked?
 118 -----------------------------
 119
 120 $CTDB determines how to invoke the ctdb client.  If not already set
 121 and if $VALGRIND is set, this is set to "$VALGRIND ctdb".  If this is
 122 not already set but $VALGRIND is not set, this is simply set to "ctdb"