1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
Introduction
------------
For a developer, the simplest way of running most tests on a local
machine from within the git repository is:
make test
This runs all UNIT and INTEGRATION tests.
tests/run_tests.sh
------------------
This script can be used to manually run all tests or selected tests,
with a variety of options. For usage, run:
tests/run_tests.sh -h
If no tests are specified this runs all of the UNIT and INTEGRATION
tests.
By default:
* INTEGRATION tests are run against 3 local daemons
* When testing is complete, a summary showing a list is printed
showing the tests run and their results
Tests can be selected in various ways:
* tests/run_tests.sh UNIT INTEGRATION
runs all UNIT and INTEGRATION tests, and is like specifying no tests
* tests/run_tests.sh UNIT/tool
runs all of the "tool" UNIT tests
* tests/run_tests.sh tests/UNIT/eventscripts/00.ctdb.setup.001.sh
tests/run_tests.sh tests/INTEGRATION/simple/basics.001.listnodes.sh
each runs a single specified test case
* tests/run_tests.sh UNIT/eventscripts UNIT/tool tests/UNIT/onnode/0001.sh
runs a combination of UNIT test suites and a single UNIT test
Testing on a cluster
--------------------
INTEGRATION and CLUSTER tests can be run on a real or virtual cluster
using tests/run_cluster_tests.sh (or "tests/run_tests.sh -c"). The
test code needs to be available on all cluster nodes, as well as the
test client node. The test client node needs to have a nodes file
where the onnode(1) command will find it.
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.
Alternatively, the tests can be installed on all nodes. One technique
is to build a package containing the tests and install it on all
nodes. CTDB developers do a lot of testing this way using the
provided sample packaging, which produces a ctdb-tests RPM package.
Finally, if the test code is installed in a different place on the
cluster nodes, then CTDB_TEST_REMOTE_DIR can be set on the test client
node to point to a directory that contains the test_wrap script on the
cluster nodes.
Running tests under valgrind
----------------------------
The easiest way of doing this is something like:
VALGRIND="valgrind -q" tests/run_tests ...
This can be used to cause all invocations of the ctdb tool, test
programs and, with local daemons, the ctdbd daemons themselves to run
under valgrind.
How is the ctdb tool invoked?
-----------------------------
$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"
Test and debugging variable options
-----------------------------------
CTDB_TEST_MODE
Set this environment variable to enable test mode.
This enables daemons and tools to locate their socket and
PID file relative to CTDB_BASE.
When testing with multiple local daemons on a single
machine this does 3 extra things:
* Disables checks related to public IP addresses
* Speeds up the initial recovery during startup at the
expense of some consistency checking
* Disables real-time scheduling
CTDB_DEBUG_HUNG_SCRIPT_LOGFILE=FILENAME
FILENAME specifies where log messages should go when
debugging hung eventscripts. This is a testing option. See
also CTDB_DEBUG_HUNG_SCRIPT.
No default. Messages go to stdout/stderr and are logged to
the same place as other CTDB log messages.
CTDB_SYS_ETCDIR=DIRECTORY
DIRECTORY containing system configuration files. This is
used to provide alternate configuration when testing and
should not need to be changed from the default.
Default is /etc.
CTDB_RUN_TIMEOUT_MONITOR=yes|no
Whether CTDB should simulate timing out monitor
events in local daemon tests.
Default is no.
CTDB_TEST_SAMBA_VERSION=VERSION
VERSION is a 32-bit number containing the Samba major
version in the most significant 16 bits and the minor
version in the least significant 16 bits. This can be
used to test CTDB's checking of incompatible versions
without installing an incompatible version. This is
probably best set like this:
export CTDB_TEST_SAMBA_VERSION=$(( (4 << 16) | 12 ))
CTDB_VARDIR=DIRECTORY
DIRECTORY containing CTDB files that are modified at runtime.
Defaults to /usr/local/var/lib/ctdb.
|
