Browse Source

Merge `doc/unit-tests.md` into `src/test/README.md`

Refer to the right file in the top-level README.md.

Having only one file with test documentation saves some confusion about
where things are documented.
0.14
Wladimir J. van der Laan 8 years ago
parent
commit
eedc461882
  1. 5
      README.md
  2. 1
      doc/README.md
  3. 18
      doc/unit-tests.md
  4. 45
      src/test/README.md

5
README.md

@ -49,9 +49,10 @@ lots of money.
### Automated Testing ### Automated Testing
Developers are strongly encouraged to write [unit tests](/doc/unit-tests.md) for new code, and to Developers are strongly encouraged to write [unit tests](src/test/README.md) for new code, and to
submit new unit tests for old code. Unit tests can be compiled and run submit new unit tests for old code. Unit tests can be compiled and run
(assuming they weren't disabled in configure) with: `make check` (assuming they weren't disabled in configure) with: `make check`. Further details on running
and extending unit tests can be found in [/src/test/README.md](/src/test/README.md).
There are also [regression and integration tests](/qa) of the RPC interface, written There are also [regression and integration tests](/qa) of the RPC interface, written
in Python, that are run automatically on the build server. in Python, that are run automatically on the build server.

1
doc/README.md

@ -53,7 +53,6 @@ The Bitcoin repo's [root README](/README.md) contains relevant information on th
- [Source Code Documentation (External Link)](https://dev.visucore.com/bitcoin/doxygen/) - [Source Code Documentation (External Link)](https://dev.visucore.com/bitcoin/doxygen/)
- [Translation Process](translation_process.md) - [Translation Process](translation_process.md)
- [Translation Strings Policy](translation_strings_policy.md) - [Translation Strings Policy](translation_strings_policy.md)
- [Unit Tests](unit-tests.md)
- [Travis CI](travis-ci.md) - [Travis CI](travis-ci.md)
- [Unauthenticated REST Interface](REST-interface.md) - [Unauthenticated REST Interface](REST-interface.md)
- [Shared Libraries](shared-libraries.md) - [Shared Libraries](shared-libraries.md)

18
doc/unit-tests.md

@ -1,18 +0,0 @@
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 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.

45
src/test/README.md

@ -1,4 +1,36 @@
# Notes ### 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 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 The sources in this directory are unit test cases. Boost includes a
unit testing framework, and since bitcoin already uses boost, it makes unit testing framework, and since bitcoin already uses boost, it makes
sense to simply use this framework rather than require developers to sense to simply use this framework rather than require developers to
@ -19,17 +51,6 @@ For further reading, I found the following website to be helpful in
explaining how the boost unit test framework works: explaining how the boost unit test framework works:
[http://www.alittlemadness.com/2009/03/31/c-unit-testing-with-boosttest/](http://www.alittlemadness.com/2009/03/31/c-unit-testing-with-boosttest/). [http://www.alittlemadness.com/2009/03/31/c-unit-testing-with-boosttest/](http://www.alittlemadness.com/2009/03/31/c-unit-testing-with-boosttest/).
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.
### bitcoin-util-test.py ### bitcoin-util-test.py
The test directory also contains the bitcoin-util-test.py tool, which tests bitcoin utils (currently just bitcoin-tx). This test gets run automatically during the `make check` build process. It is also possible to run the test manually from the src directory: The test directory also contains the bitcoin-util-test.py tool, which tests bitcoin utils (currently just bitcoin-tx). This test gets run automatically during the `make check` build process. It is also possible to run the test manually from the src directory:

Loading…
Cancel
Save