27a196b126
When #3303 was merged, a cyclic dependency chain was generated: libdevice <- libcncrypto <- libringct <- libdevice This was because libdevice needs access to a set of basic crypto operations implemented in libringct such as scalarmultBase(), while libringct also needs access to abstracted crypto operations implemented in libdevice such as ecdhEncode(). To untangle this cyclic dependency chain, this patch splits libringct into libringct_basic and libringct, where the basic crypto ops previously in libringct are moved into libringct_basic. The cyclic dependency is now resolved thanks to this separation: libcncrypto <- libringct_basic <- libdevice <- libcryptonote_basic <- libringct This eliminates the need for crypto_device.cpp and rctOps_device.cpp. Also, many abstracted interfaces of hw::device such as encrypt_payment_id() and get_subaddress_secret_key() were previously implemented in libcryptonote_basic (cryptonote_format_utils.cpp) and were then called from hw::core::device_default, which is odd because libdevice is supposed to be independent of libcryptonote_basic. Therefore, those functions were moved to device_default.cpp. |
||
|---|---|---|
| .. | ||
| core_proxy | ||
| core_tests | ||
| crypto | ||
| daemon_tests | ||
| data | ||
| difficulty | ||
| functional_tests | ||
| fuzz | ||
| gtest | ||
| hash | ||
| libwallet_api_tests | ||
| net_load_tests | ||
| performance_tests | ||
| 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
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.hcontains test harness headersmain.cppimplements 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]
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
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]