2d46f1be0c
04cca330944f859b4ed68cb8da8a79f5206fd630 Style cleanup. (Jim Posen) 4c01e4e159db82ce4b2acce75f709cac996367d7 flatfile: Unit tests for FlatFileSeq methods. (Jim Posen) 65a489e93d181d3c0f7a9cf79f7c11ff8cf2b0f0 scripted-diff: Rename CBlockDiskPos to FlatFilePos. (Jim Posen) d6d8a78f26f52fdfe43293686135e2fc6919926c Move CDiskBlockPos from chain to flatfile. (Jim Posen) e0380933e3745214331d358bda8c5e79299c84d2 validation: Refactor file flush logic into FlatFileSeq. (Jim Posen) 992404b31ed2f8cabeed59d074552f0ae10fda94 validation: Refactor block file pre-allocation into FlatFileSeq. (Jim Posen) e2d2abb99fe353ffc2ff3bc1ff578fad31065335 validation: Refactor OpenDiskFile into method on FlatFileSeq. (Jim Posen) 9183d6ef656c8f3ed406821b99827f9b5f047665 validation: Extract basic block file logic into FlatFileSeq class. (Jim Posen) 62e7addb632cad77cbd5fbccbaee51c7b32505d0 util: Move CheckDiskSpace to util. (Jim Posen) Pull request description: This cleans up and refactors block file helpers so that they may be used by the block filter indexer. Per [design discussion](https://github.com/bitcoin/bitcoin/pull/14121#issuecomment-451252591) about storing BIP 157 block filters, it has been suggested that they are stored in the same way as block and undo data. This refactor is sufficient to simplify file operations for this use case, though in the future perhaps more pruning-related logic ought to be moved into the new classes. The basic abstraction is a `FlatFileSeq` which manages access to a sequence of numbered files into which raw data is written. Tree-SHA512: b2108756777f2dad8964a1a2ef2764486e708a4a4a8cfac47b5de8bcb0625388964438eb096b10cfd9ea39212c299b5cb32fa943e768db2333cf49ea7def157e
Compiling/running unit tests
Unit tests will be automatically compiled if dependencies were met in ./configure
and tests weren't explicitly disabled.
After configuring, they can be run with make check.
To run the bitcoind tests manually, launch src/test/test_bitcoin. To recompile
after a test file was modified, run make and then run the test again. If you
modify a non-test file, use make -C src/test to recompile only what's needed
to run the bitcoind tests.
To add more bitcoind tests, add BOOST_AUTO_TEST_CASE functions to the existing
.cpp files in the test/ directory or add new .cpp files that
implement new BOOST_AUTO_TEST_SUITE sections.
To run the bitcoin-qt tests manually, launch src/qt/test/test_bitcoin-qt
To add more bitcoin-qt tests, add them to the src/qt/test/ directory and
the src/qt/test/test_main.cpp file.
Running individual tests
test_bitcoin has some built-in command-line arguments; for example, to run just the getarg_tests verbosely:
test_bitcoin --log_level=all --run_test=getarg_tests
... or to run just the doubledash test:
test_bitcoin --run_test=getarg_tests/doubledash
Run test_bitcoin --help for the full list.
Note on adding test cases
The sources in this directory are unit test cases. Boost includes a unit testing framework, and since bitcoin already uses boost, it makes sense to simply use this framework rather than require developers to configure some other framework (we want as few impediments to creating unit tests as possible).
The build system is setup to compile an executable called test_bitcoin
that runs all of the unit tests. The main source file is called
test_bitcoin.cpp. To add a new unit test file to our test suite you need
to add the file to src/Makefile.test.include. The pattern is to create
one test file for each class or source file for which you want to create
unit tests. The file naming convention is <source_filename>_tests.cpp
and such files should wrap their tests in a test suite
called <source_filename>_tests. For an example of this pattern,
examine uint256_tests.cpp.
For further reading, I found the following website to be helpful in explaining how the boost unit test framework works: http://www.alittlemadness.com/2009/03/31/c-unit-testing-with-boosttest/.