11# Unit tests
22
3- The sources in this directory are unit test cases. Boost includes a
4- unit testing framework, and since Bitcoin Core already uses Boost, it makes
5- sense to simply use this framework rather than require developers to
6- configure some other framework (we want as few impediments to creating
7- unit tests as possible).
3+ The sources in this directory are unit test cases. Tests use a small
4+ header-only framework declared in ` src/test/util/framework.hpp ` , which
5+ provides registration macros (` TEST_CASE ` , ` FIXTURE_TEST_CASE ` ,
6+ ` TEST_SUITE_BEGIN ` /` TEST_SUITE_END ` ) and assertion macros (` CHECK ` ,
7+ ` REQUIRE ` , ` CHECK_THROWS ` , ` CHECK_THROWS_AS ` , ` CHECK_EXCEPTION ` ,
8+ ` CHECK_EQUAL_RANGES ` , ` TEST_MESSAGE ` , ` WARN_MESSAGE ` ).
89
910The build system is set up to compile an executable called ` test_bitcoin `
1011that runs all of the unit tests. The main source file for the test library is found in
@@ -22,27 +23,26 @@ and tests weren't explicitly disabled.
2223The unit tests can be run with ` ctest --test-dir build ` , which includes unit
2324tests from subtrees.
2425
25- Run ` build/bin/test_bitcoin --list_content ` for the full list of tests.
26+ Run ` build/bin/test_bitcoin --list ` for the full list of tests.
2627
2728To run the unit tests manually, launch ` build/bin/test_bitcoin ` . To recompile
2829after a test file was modified, run ` cmake --build build ` and then run the test again. If you
2930modify a non-test file, use ` cmake --build build --target test_bitcoin ` to recompile only what's needed
3031to run the unit tests.
3132
32- To add more unit tests, add ` BOOST_AUTO_TEST_CASE ` functions to the existing
33- .cpp files in the ` test/ ` directory or add new .cpp files that
34- implement new ` BOOST_AUTO_TEST_SUITE ` sections .
33+ To add more unit tests, add ` TEST_CASE ` (or ` FIXTURE_TEST_CASE ` ) functions to
34+ the existing .cpp files in the ` test/ ` directory, or add new .cpp files that
35+ declare a new suite with ` TEST_SUITE_BEGIN("<name>") ` .
3536
3637### Running individual tests
3738
38- The ` test_bitcoin ` runner accepts command line arguments from the Boost
39- framework. To see the list of arguments that may be passed, run:
39+ To see the list of arguments that may be passed, run:
4040
4141```
4242build/bin/test_bitcoin --help
4343```
4444
45- For example, to run only the tests in the ` getarg_tests ` file , with full logging:
45+ For example, to run only the tests in the ` getarg_tests ` suite , with full logging:
4646
4747``` bash
4848build/bin/test_bitcoin --log_level=all --run_test=getarg_tests
5454build/bin/test_bitcoin -l all -t getarg_tests
5555```
5656
57- or to run only the doubledash test in ` getarg_tests `
57+ or to run only the ` doubledash ` test in ` getarg_tests `
5858
5959``` bash
60- build/bin/test_bitcoin --run_test=getarg_tests/ doubledash
60+ build/bin/test_bitcoin --run_test=getarg_tests:: doubledash
6161```
6262
6363The ` --log_level= ` (or ` -l ` ) argument controls the verbosity of the test output.
64+ Accepted values: ` none ` , ` error ` (default), ` info ` , ` all ` .
6465
6566The ` test_bitcoin ` runner also accepts some of the command line arguments accepted by
6667` bitcoind ` . Use ` -- ` to separate these sets of arguments:
@@ -126,8 +127,10 @@ additionally use the `--output-on-failure` option to display logs of the failed
126127on failure. For running individual tests verbosely, refer to the section
127128[ above] ( #running-individual-tests ) .
128129
129- To write to logs from unit tests you need to use specific message methods
130- provided by Boost. The simplest is ` BOOST_TEST_MESSAGE ` .
130+ To write a diagnostic message from a unit test, use ` TEST_MESSAGE(...) `
131+ (emitted at log level ` info ` or higher). ` WARN_MESSAGE(cond, msg) ` emits
132+ a warning when ` cond ` is false without failing the test — use ` CHECK ` /
133+ ` REQUIRE ` to fail.
131134
132135For debugging you can launch the ` test_bitcoin ` executable with ` gdb ` or ` lldb ` and
133136start debugging, just like you would with any other program:
@@ -146,13 +149,9 @@ Another tool that can be used to resolve segmentation faults is
146149[ valgrind] ( https://valgrind.org/ ) .
147150
148151If for whatever reason you want to produce a core dump file for this fault, you can do
149- that as well. By default, the boost test runner will intercept system errors and not
150- produce a core file. To bypass this, add ` --catch_system_errors=no ` to the
151- ` test_bitcoin ` arguments and ensure that your ulimits are set properly (e.g. `ulimit -c
152- unlimited`).
153-
154- Running the tests and hitting a segmentation fault should now produce a file called ` core `
155- (on Linux platforms, the file name will likely depend on the contents of
152+ that as well. Ensure that your ulimits are set properly (e.g. ` ulimit -c unlimited ` ),
153+ then running the tests and hitting a segmentation fault should produce a file called
154+ ` core ` (on Linux platforms, the file name will likely depend on the contents of
156155` /proc/sys/kernel/core_pattern ` ).
157156
158157You can then explore the core dump using
0 commit comments