619ea6923f
3d6a22ea05df70d6f0c11f2f00c85dc16975ad28 feat: add rpc command to list revealed addresses (Michael Mallan) 4945dba7c066d1434fa38a09a955339b7182e693 feat: add command to list revealed addresses (Michael Mallan) 75f37708b3b1f6a89e0f5488c95618a07356f166 test: implement methods for getting/setting labels (Michael Mallan) 16b96b5456b46cd3703d4829b24746c8a489b3ed style: apply black formatting (Michael Mallan) Pull request description: This implements #1678. The command parameters differ slightly from those described in the issue: - instead of a `keychain` enum parameter, I used `is_change` to control whether receive or change addresses are returned. - I used an optional `continue_from` parameter to control pagination. The value to pass in the next request is provided by the previous response. If no value is provided in the response, there are no more addresses to list. If no value is set in the request, the addresses will be returned starting from the last revealed address. Setting the positional argument for `continue_after` as `null` will be treated the same as omitting it (for other RPC commands, a `null` value results in a parsing error). ACKs for top commit: pythcoiner: utACK 3d6a22e Tree-SHA512: 0efa93bc40d0751cbe64570f9789b3a701e0bc5aab982da9ed9f21117a2eea073a81388370d56a9021c0ff87b6cbaec7338339427e6c879e8e97eababb107f57
Lianad blackbox tests
Here we test lianad by starting it on a regression testing Bitcoin network,
and by then talking to it as an user would, from the outside.
Python scripts are used for the automation, and specifically the pytest framework.
Credits: this test framework was taken and adapted from revaultd, which was itself adapted from C-lightning's test framework.
Building the project for testing
To run the tests, we must build the debug version of lianad. Follow the instructions at doc/BUILD.md but instead of running
$ cargo build --release
Run
$ cargo build
to build the daemon for testing.
The lianad and liana-cli binaries will be in the target/debug directory at the root of the
repository.
Test dependencies
Before running the tests, you might need to install some system packages. Here's an example for Ubuntu:
sudo apt update
sudo apt install build-essential libssl-dev libffi-dev python3-dev
sudo apt install autoconf automake libtool
Functional tests dependencies can be installed using pip. Use a virtual environment.
# Create a new virtual environment, preferably.
python3 -m venv venv
. venv/bin/activate
# Get the deps
pip install -r tests/requirements.txt
Additionally you need to have bitcoind installed on your computer, please
refer to bitcoincore for installation. You may use a
specific bitcoind binary by specifying the BITCOIND_PATH env var.
Running the tests
From the root of the repository:
pytest tests/
For running the tests under Taproot a bitcoind version 26.0 or superior must be used. It can be
pointed to using the BITCOIND_PATH variable. For now, one must also compile the taproot_signer
Rust program:
(cd tests/tools/taproot_signer && cargo build --release)
Then the test suite can be run by using Taproot descriptors instead of P2WSH descriptors by setting
the USE_TAPROOT environment variable to 1.
Tips and tricks
Logging
We use the Live Logging
functionality from pytest. It is configured in (pyproject.toml)[../pyproject.toml] to
output INFO-level to the console. If a test fails, the entire DEBUG log is output.
You can override the config at runtime with the --log-cli-level option:
pytest -vvv --log-cli-level=DEBUG -k test_startup
Note that we record all logs from daemons, and we start them with log_level = "debug".
Running tests in parallel
In order to run tests in parallel, you can use -n arg:
pytest -n 8 tests/
Test lints
Just use black.
More
See the environment variables in test_framework/utils.py.