tests: Update README files and add new README files where missing
[vlendec/samba-autobuild/.git] / 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.
18
19 scripts/run_tests
20 -----------------
21
22 The above scripts invoke tests/scripts/run_tests.  This script has a
23 lot of command-line switches.  Some of the more useful options
24 include:
25
26   -s  Print a summary of tests results after running all tests
27
28   -l  Use local daemons for integration tests
29
30       This allows the tests in "simple" to be run against local
31       daemons.
32
33       All integration tests communicate with cluster nodes using
34       onnode or the ctdb tool, which both have some test hooks to
35       support local daemons.
36
37       By default 3 daemons are used.  If you want to use a different
38       number of daemons then do not use this option but set
39       TEST_LOCAL_DAEMONS to the desired number of daemons instead.
40       The -l option just sets TEST_LOCAL_DAEMONS to 3...  :-)
41
42   -e  Exit on the first test failure
43
44   -H  No headers - for running single test with other wrapper
45
46       This allows tests to be embedded in some other test framework
47       and executed one-by-one with all the required
48       environment/infrastructure.
49
50       This replaces the old ctdb_test_env script.
51
52 How do the tests find remote test programs?
53 -------------------------------------------
54
55 If the all of the cluster nodes have the CTDB git tree in the same
56 location as on the test client then no special action is necessary.
57 The simplest way of doing this is to share the tree to cluster nodes
58 and test clients via NFS.
59
60 If cluster nodes do not have the CTDB git tree then
61 CTDB_TEST_REMOTE_DIR can be set to a directory that, on each cluster
62 node, contains the contents of tests/scripts/ and tests/bin/.
63
64 In the future this will hopefully (also) be supported via a ctdb-test
65 package.
66
67 Running the ctdb tool under valgrind
68 ------------------------------------
69
70 The easiest way of doing this is something like:
71
72   VALGRIND="valgrind -q" scripts/run_tests ...
73
74 This can be used to cause all invocations of the ctdb client (and,
75 with local daemons, the ctdbd daemons themselves) to occur under
76 valgrind.
77
78 NOTE: Some libc calls seem to do weird things and perhaps cause
79 spurious output from ctdbd at start time.  Please read valgrind output
80 carefully before reporting bugs.  :-)
81
82 How is the ctdb tool invoked?
83 -----------------------------
84
85 $CTDB determines how to invoke the ctdb client.  If not already set
86 and if $VALGRIND is set, this is set to "$VALGRIND ctdb".  If this is
87 not already set but $VALGRIND is not set, this is simply set to "ctdb"