Skip to content

Commit 7c87a9c

Browse files
committed
Merge #10612: The young person's guide to the test_framework
e7ba6c1 [tests] add example test (John Newbery) 76859e6 [tests] Update functional tests documentation (John Newbery) Tree-SHA512: 74eb464e965e16466f95b9eda7d1e89a31ef1ef204dd30e1b11ddf482336f12f33fa5ca3cc733b6eaf440c46401e663585af9caca202deddb440bbadce964a62
2 parents 1680ee0 + e7ba6c1 commit 7c87a9c

File tree

4 files changed

+441
-107
lines changed

4 files changed

+441
-107
lines changed

test/README.md

Lines changed: 111 additions & 43 deletions
Original file line numberDiff line numberDiff line change
@@ -15,84 +15,152 @@ The util tests are run as part of `make check` target. The functional
1515
tests are run by the travis continuous build process whenever a pull
1616
request is opened. Both sets of tests can also be run locally.
1717

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+
2026
The ZMQ functional test requires a python ZMQ library. To install it:
2127

2228
- on Unix, run `sudo apt-get install python3-zmq`
2329
- on mac OS, run `pip3 install pyzmq`
2430

25-
Running tests locally
26-
=====================
31+
#### Running the tests
2732

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:
2934

30-
Functional tests
31-
----------------
35+
```
36+
test/functional/replace-by-fee.py
37+
```
3238

33-
You can run any single test by calling
39+
or can be run through the test_runner harness, eg:
3440

35-
test/functional/test_runner.py <testname>
41+
```
42+
test/functional/test_runner.py replace-by-fee.py
43+
```
3644

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:
3846

39-
test/functional/test_runner.py <testname1> <testname2> <testname3> ...
47+
```
48+
test/functional/test_runner.py <testname1> <testname2> <testname3> ...
49+
```
4050

41-
Run the regression test suite with
51+
Run the regression test suite with:
4252

43-
test/functional/test_runner.py
53+
```
54+
test/functional/test_runner.py
55+
```
4456

4557
Run all possible tests with
4658

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`
4865

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.
5168

52-
If you want to create a basic coverage report for the RPC test suite, append `--coverage`.
69+
#### Troubleshooting and debugging test failures
5370

54-
Possible options, which apply to each individual test run:
71+
##### Resource contention
5572

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
5690
```
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-
```
6791

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+
```
7097

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.
7598

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
79100

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):
82107

83108
```bash
84109
rm -rf cache
85110
killall bitcoind
86111
```
87112

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
90159

91160
Util tests can be run locally by running `test/util/bitcoin-util-test.py`.
92161
Use the `-v` option for verbose output.
93162

94-
Writing functional tests
95-
========================
163+
# Writing functional tests
96164

97165
You are encouraged to write functional tests for new or existing features.
98166
Further information about the functional test framework and individual

0 commit comments

Comments
 (0)