70b9fed4fd
This adds a static dependency script for libraries like boost, unbound, etc. to cmake, invokable with: cmake .. -DBUILD_STATIC_DEPS=ON which downloads and builds static versions of all our required dependencies (boost, unbound, openssl, ncurses, etc.). It also implies -DSTATIC=ON to build other vendored deps (like miniupnpc, lokimq) as static as well. Unlike the contrib/depends system, this is easier to maintain (one script using nicer cmake with functions instead of raw Makefile spaghetti code), and isn't concerned with reproducible builds -- this doesn't rebuild the compiler, for instance. It also works with the existing build system so that it is simply another way to invoke the cmake build scripts but doesn't require any external tooling. This works on Linux, Mac, and Windows. Some random comments on this commit (for preserving history): - Don't use target_link_libraries on imported targets. Newer cmake is fine with it, but Bionic's cmake doesn't like it but seems okay with setting the properties directly. - This rebuilds libzmq and libsodium, even though there is some provision already within loki-core to do so: however, the existing embedded libzmq fails with the static deps because it uses libzmq's cmake build script, which relies on pkg-config to find libsodium which ends up finding the system one (or not finding any), rather than the one we build with DownloadLibSodium. Since both libsodium and libzmq are faily simple builds it seemed easiest to just add them to the cmake static build rather than trying to shoehorn the current code into the static build script. - Half of the protobuf build system ignores CC/CXX just because Google, and there's no documentation anywhere except for a random closed bug report about needing to set these other variables (CC_FOR_BUILD, CXX_FOR_BUILD) instead, but you need to. Thanks Google. - The boost build is set to output very little because even the minimum -d1 output level spams ~15k lines of output just for the headers it installs. |
||
---|---|---|
.. | ||
block_weight | ||
core_proxy | ||
core_tests | ||
crypto | ||
daemon_tests | ||
data | ||
difficulty | ||
functional_tests | ||
fuzz | ||
gtest | ||
hash | ||
libwallet_api_tests | ||
net_load_tests | ||
network_tests | ||
performance_tests | ||
trezor | ||
unit_tests | ||
CMakeLists.txt | ||
cryptolib.pl | ||
cryptotest.pl | ||
hash-target.cpp | ||
io.h | ||
README.md |
Running all tests
To run all tests, run:
cd /path/to/monero
make [-jn] debug-test # where n is number of compiler processes
To test a release build, replace debug-test
with release-test
in the previous command.
Core tests
Core tests take longer than any other Monero tests, due to the high amount of computational work involved in validating core components.
Tests are located in tests/core_tests/
, and follow a straightforward naming convention. Most cases cover core functionality (block_reward.cpp
, chaingen.cpp
, rct.cpp
, etc.), while some cover basic security tests (double_spend.cpp
& integer_overflow.cpp
).
To run only Monero's core tests (after building):
cd build/debug/tests/core_tests
ctest
To run the same tests on a release build, replace debug
with release
.
Crypto Tests
Crypto tests are located under the tests/crypto
directory.
crypto-tests.h
contains test harness headersmain.cpp
implements the driver for the crypto tests
Tests correspond to components under src/crypto/
. A quick comparison reveals the pattern, and new tests should continue the naming convention.
To run only Monero's crypto tests (after building):
cd build/debug/tests/crypto
ctest
To run the same tests on a release build, replace debug
with release
.
Daemon tests
[TODO]
Functional tests
[TODO]
Functional tests are located under the tests/functional
directory.
First, run a regtest daemon in the offline mode and with a fixed difficulty:
monerod --regtest --offline --fixed-difficulty 1
Alternatively, you can run multiple daemons and let them connect with each other by using --add-exclusive-node
. In this case, make sure that the same fixed difficulty is given to all the daemons.
Next, restore a mainnet wallet with the following seed and restore height 0 (the file path doesn't matter):
velvet lymph giddy number token physics poetry unquoted nibs useful sabotage limits benches lifestyle eden nitrogen anvil fewest avoid batch vials washing fences goat unquoted
Open the wallet file with monero-wallet-rpc
with RPC port 18083. Finally, start tests by invoking ./blockchain.py or ./speed.py
Fuzz tests
Fuzz tests are written using American Fuzzy Lop (AFL), and located under the tests/fuzz
directory.
An additional helper utility is provided contrib/fuzz_testing/fuzz.sh
. AFL must be installed, and some additional setup may be necessary for the script to run properly.
Hash tests
Hash tests exist under tests/hash
, and include a set of target hashes in text files.
To run only Monero's hash tests (after building):
cd build/debug/tests/hash
ctest
To run the same tests on a release build, replace debug
with release
.
Libwallet API tests
[TODO]
Net Load tests
[TODO]
Performance tests
Performance tests are located in tests/performance_tests
, and test features for performance metrics on the host machine.
To run only Monero's performance tests (after building):
cd build/debug/tests/performance_tests
./performance_tests
The path may be build/Linux/master/debug (adapt as necessary for your platform).
If the performance_tests
binary does not exist, try running make
in the build/debug/tests/performance_tests
directory.
To run the same tests on a release build, replace debug
with release
.
Unit tests
Unit tests are defined under the tests/unit_tests
directory. Independent components are tested individually to ensure they work properly on their own.
To run only Monero's unit tests (after building):
cd build/debug/tests/unit_tests
ctest
To run the same tests on a release build, replace debug
with release
.
Writing new tests
Test hygiene
When writing new tests, please implement all functions in .cpp
or .c
files, and only put function headers in .h
files. This will help keep the fairly complex test suites somewhat sane going forward.
Writing fuzz tests
[TODO]