Previous Bitcoin Core PR review club sessions
A good starting point is the various Bitcoin Core PR review club sessions that have been held thus far on specific commits of the Taproot PR. The latest one was on "Implement Taproot validation" (hosted by John Newbery) and there are various notes and a transcript of the meeting there. There are also ...
The functional tests test the RPCs. The unit tests test the C++ code directly by calling the functions.
The functional test frameworks uses a version of python-bitcoinrpc which can be found here. This library allows the test framework to call RPC commands as if they were python functions; authproxy handles the conversion to HTTP POST requests for the RPC ...
This was answered on Twitter by various individuals.
You should remove the directory /tmp/test_common_Bitcoin Core regularly. For Martin Leitner-Ankerl this was 6GB of leftover files (leftovers only happen when tests fail or are canceled).
theStack also recommends running rm -rf /tmp/bitcoin_func_test_* every now and then.
The /tmp directory is usually only ...
The default setup_network() implemented by the test framework connects all nodes, as explained by the comment in example_test.py's setup_network(). Since you want node 2 to be connected to nodes 1 and 0, you can simply delete the setup_network() implemented in example_test.py to use the default setup_network(). Then inside of run_test(), you can just do ....
To understand the functional tests, I think it's important to start with an understanding of how bitcoind works and how the RPC interface is used.
Start Bitcoin Core in a terminal window in regtest mode (a local test network that does not connect to any peers by default):
$ bitcoind -regtest
Keep an eye on the output! This is your debug log, and important ...
Marco Falke has a site that analyzes the current line, function and branch coverage for unit tests, functional tests and fuzz tests.
Alternatively, vasild runs clang's tools and then a script to highlight which lines in the coverage report have been modified by a particular patch (PR).
If you watched Fabian's presentation (or read the transcript) you'll have seen that he said you can use Valgrind for memory leak checks and that it can be used similarly to lldb.
valgrind --leak-check=yes src/bitcoind -regtest
There is a section in Fabian's doc on debugging Bitcoin with instructions on how to install Valgrind on MacOS and run it.
When you run P2P functional tests you are spinning up regtest nodes (running simplified Python code) that connect to your full node (running the full C++ code) to test P2P functionality.
As John Newbery outlines here:
A node is the bitcoind instance. This is the thing whose behavior
is being tested. Each bitcoind node is managed by a Python TestNode
The Bitcoin Core test README states:
By default, up to 4 tests will be run in parallel by test_runner. To
specify how many jobs to run, append --jobs=n
The individual tests and the test_runner harness have many
command-line options. Run test/functional/test_runner.py -h to see
Pieter Wuille also explained how he gets the total time down below 4 ...
These bip340_test_vectors are used in two places: the unit tests (src/test/key_tests.cpp) and the functional tests (test/functional/test_framework/key.py).
The Python code for testing the bip340_test_vectors is here.
There are 15 test cases in all but only 4 distinct secret keys, 7 distinct public keys (3 of them don't have secret keys) and 15 distinct ...
script.py of the Bitcoin Core functional test framework contains a comment that it was initially modified from python-bitcoinlib.
There doesn't appear to have been any code sharing beyond that and certainly not any later changes pushed up/downstream.
I asked Kanzure (previous maintainer of python-bitcoinlib) on IRC about it and he said:
python-bitcoinlib is ...
What backward compatibility testing is done to ensure the latest release passes previous releases' versions of the functional tests?
There is a feature_backwards_compatibility.py functional test which spins up functional test nodes from each of the previous releases to do testing between them at the same time.
Once you have built the latest version of ...
PR #8836 was one of John Newbery's earlier contributions to Bitcoin Core. He introduced this code so that bitcoin-util-test.py would fail when the output_cmp file is empty.
if not outputData:
print("Output data missing for " + outputFn)
PR #16445 was Fabian Jahr's first contribution to Bitcoin Core. One ...
There are a few different resources I would point you to.
For more information on functional tests in Bitcoin Core (with guidance on writing them) I would check out the functional tests README.
For a case study on debugging the functional tests Sjors Provoost wrote a blog post back in 2017. (Some of it may now be outdated but the general thought process is ...