@@ -15,84 +15,152 @@ The util tests are run as part of `make check` target. The functional
15
15
tests are run by the travis continuous build process whenever a pull
16
16
request is opened. Both sets of tests can also be run locally.
17
17
18
- Functional Test dependencies
19
- ============================
18
+ # Running tests locally
19
+
20
+ Build for your system first. Be sure to enable wallet, utils and daemon when you configure. Tests will not run otherwise.
21
+
22
+ ### Functional tests
23
+
24
+ #### Dependencies
25
+
20
26
The ZMQ functional test requires a python ZMQ library. To install it:
21
27
22
28
- on Unix, run ` sudo apt-get install python3-zmq `
23
29
- on mac OS, run ` pip3 install pyzmq `
24
30
25
- Running tests locally
26
- =====================
31
+ #### Running the tests
27
32
28
- Build for your system first. Be sure to enable wallet, utils and daemon when you configure. Tests will not run otherwise.
33
+ Individual tests can be run by directly calling the test script, eg:
29
34
30
- Functional tests
31
- ----------------
35
+ ```
36
+ test/functional/replace-by-fee.py
37
+ ```
32
38
33
- You can run any single test by calling
39
+ or can be run through the test_runner harness, eg:
34
40
35
- test/functional/test_runner.py <testname>
41
+ ```
42
+ test/functional/test_runner.py replace-by-fee.py
43
+ ```
36
44
37
- Or you can run any combination (incl. duplicates) of tests by calling
45
+ You can run any combination (incl. duplicates) of tests by calling:
38
46
39
- test/functional/test_runner.py <testname1> <testname2> <testname3> ...
47
+ ```
48
+ test/functional/test_runner.py <testname1> <testname2> <testname3> ...
49
+ ```
40
50
41
- Run the regression test suite with
51
+ Run the regression test suite with:
42
52
43
- test/functional/test_runner.py
53
+ ```
54
+ test/functional/test_runner.py
55
+ ```
44
56
45
57
Run all possible tests with
46
58
47
- test/functional/test_runner.py --extended
59
+ ```
60
+ test/functional/test_runner.py --extended
61
+ ```
62
+
63
+ By default, up to 4 tests will be run in parallel by test_runner. To specify
64
+ how many jobs to run, append ` --jobs=n `
48
65
49
- By default, tests will be run in parallel. To specify how many jobs to run,
50
- append ` --jobs=n ` (default n=4) .
66
+ The individual tests and the test_runner harness have many command-line
67
+ options. Run ` test_runner.py -h ` to see them all .
51
68
52
- If you want to create a basic coverage report for the RPC test suite, append ` --coverage ` .
69
+ #### Troubleshooting and debugging test failures
53
70
54
- Possible options, which apply to each individual test run:
71
+ ##### Resource contention
55
72
73
+ The P2P and RPC ports used by the bitcoind nodes-under-test are chosen to make
74
+ conflicts with other processes unlikely. However, if there is another bitcoind
75
+ process running on the system (perhaps from a previous test which hasn't successfully
76
+ killed all its bitcoind nodes), then there may be a port conflict which will
77
+ cause the test to fail. It is recommended that you run the tests on a system
78
+ where no other bitcoind processes are running.
79
+
80
+ On linux, the test_framework will warn if there is another
81
+ bitcoind process running when the tests are started.
82
+
83
+ If there are zombie bitcoind processes after test failure, you can kill them
84
+ by running the following commands. ** Note that these commands will kill all
85
+ bitcoind processes running on the system, so should not be used if any non-test
86
+ bitcoind processes are being run.**
87
+
88
+ ``` bash
89
+ killall bitcoind
56
90
```
57
- -h, --help show this help message and exit
58
- --nocleanup Leave bitcoinds and test.* datadir on exit or error
59
- --noshutdown Don't stop bitcoinds after the test execution
60
- --srcdir=SRCDIR Source directory containing bitcoind/bitcoin-cli
61
- (default: ../../src)
62
- --tmpdir=TMPDIR Root directory for datadirs
63
- --tracerpc Print out all RPC calls as they are made
64
- --coveragedir=COVERAGEDIR
65
- Write tested RPC commands into this directory
66
- ```
67
91
68
- If you set the environment variable ` PYTHON_DEBUG=1 ` you will get some debug
69
- output (example: ` PYTHON_DEBUG=1 test/functional/test_runner.py wallet ` ).
92
+ or
93
+
94
+ ``` bash
95
+ pkill -9 bitcoind
96
+ ```
70
97
71
- A 200-block -regtest blockchain and wallets for four nodes
72
- is created the first time a regression test is run and
73
- is stored in the cache/ directory. Each node has 25 mature
74
- blocks (25* 50=1250 BTC) in its wallet.
75
98
76
- After the first run, the cache/ blockchain and wallets are
77
- copied into a temporary directory and used as the initial
78
- test state.
99
+ ##### Data directory cache
79
100
80
- If you get into a bad state, you should be able
81
- to recover with:
101
+ A pre-mined blockchain with 200 blocks is generated the first time a
102
+ functional test is run and is stored in test/cache. This speeds up
103
+ test startup times since new blockchains don't need to be generated for
104
+ each test. However, the cache may get into a bad state, in which case
105
+ tests will fail. If this happens, remove the cache directory (and make
106
+ sure bitcoind processes are stopped as above):
82
107
83
108
``` bash
84
109
rm -rf cache
85
110
killall bitcoind
86
111
```
87
112
88
- Util tests
89
- ----------
113
+ ##### Test logging
114
+
115
+ The tests contain logging at different levels (debug, info, warning, etc). By
116
+ default:
117
+
118
+ - when run through the test_runner harness, * all* logs are written to
119
+ ` test_framework.log ` and no logs are output to the console.
120
+ - when run directly, * all* logs are written to ` test_framework.log ` and INFO
121
+ level and above are output to the console.
122
+ - when run on Travis, no logs are output to the console. However, if a test
123
+ fails, the ` test_framework.log ` and bitcoind ` debug.log ` s will all be dumped
124
+ to the console to help troubleshooting.
125
+
126
+ To change the level of logs output to the console, use the ` -l ` command line
127
+ argument.
128
+
129
+ ` test_framework.log ` and bitcoind ` debug.log ` s can be combined into a single
130
+ aggregate log by running the ` combine_logs.py ` script. The output can be plain
131
+ text, colorized text or html. For example:
132
+
133
+ ```
134
+ combine_logs.py -c <test data directory> | less -r
135
+ ```
136
+
137
+ will pipe the colorized logs from the test into less.
138
+
139
+ Use ` --tracerpc ` to trace out all the RPC calls and responses to the console. For
140
+ some tests (eg any that use ` submitblock ` to submit a full block over RPC),
141
+ this can result in a lot of screen output.
142
+
143
+ By default, the test data directory will be deleted after a successful run.
144
+ Use ` --nocleanup ` to leave the test data directory intact. The test data
145
+ directory is never deleted after a failed test.
146
+
147
+ ##### Attaching a debugger
148
+
149
+ A python debugger can be attached to tests at any point. Just add the line:
150
+
151
+ ``` py
152
+ import pdb; pdb.set_trace()
153
+ ```
154
+
155
+ anywhere in the test. You will then be able to inspect variables, as well as
156
+ call methods that interact with the bitcoind nodes-under-test.
157
+
158
+ ### Util tests
90
159
91
160
Util tests can be run locally by running ` test/util/bitcoin-util-test.py ` .
92
161
Use the ` -v ` option for verbose output.
93
162
94
- Writing functional tests
95
- ========================
163
+ # Writing functional tests
96
164
97
165
You are encouraged to write functional tests for new or existing features.
98
166
Further information about the functional test framework and individual
0 commit comments