@@ -5,18 +5,15 @@ sense to simply use this framework rather than require developers to
5
5
configure some other framework (we want as few impediments to creating
6
6
unit tests as possible).
7
7
8
- The build system is setup to compile an executable called " test_bitcoin"
8
+ The build system is setup to compile an executable called ` test_bitcoin `
9
9
that runs all of the unit tests. The main source file is called
10
- test_bitcoin.cpp, which simply includes other files that contain the
11
- actual unit tests (outside of a couple required preprocessor
12
- directives). The pattern is to create one test file for each class or
13
- source file for which you want to create unit tests. The file naming
14
- convention is "<source_filename>_ tests.cpp" and such files should wrap
15
- their tests in a test suite called "<source_filename>_ tests". For an
16
- examples of this pattern, examine uint160_tests.cpp and
17
- uint256_tests.cpp.
18
-
19
- Add the source files to /src/Makefile.test.include to add them to the build.
10
+ test_bitcoin.cpp. To add a new unit test file to our test suite you need
11
+ to add the file to ` src/Makefile.test.include ` . The pattern is to create
12
+ one test file for each class or source file for which you want to create
13
+ unit tests. The file naming convention is ` <source_filename>_tests.cpp `
14
+ and such files should wrap their tests in a test suite
15
+ called ` <source_filename>_tests ` . For an example of this pattern,
16
+ examine ` uint256_tests.cpp ` .
20
17
21
18
For further reading, I found the following website to be helpful in
22
19
explaining how the boost unit test framework works:
@@ -31,5 +28,5 @@ example, to run just the getarg_tests verbosely:
31
28
32
29
test_bitcoin --run_test=getarg_tests/doubledash
33
30
34
- Run test_bitcoin --help for the full list.
31
+ Run ` test_bitcoin --help ` for the full list.
35
32
0 commit comments