UnitTesting » History » Version 12
Davide Pesavento, 04/21/2020 10:50 AM
1 | 1 | Junxiao Shi | # Unit Testing |
---|---|---|---|
2 | |||
3 | NFD requires unit testing for most modules. |
||
4 | |||
5 | 12 | Davide Pesavento | NFD uses the [Boost Unit Test Framework](https://www.boost.org/doc/libs/1_65_1/libs/test/doc/html/index.html). |
6 | 1 | Junxiao Shi | |
7 | ## Learning Resources for Boost Unit Test Framework |
||
8 | |||
9 | 12 | Davide Pesavento | * Boost Unit Test Framework [documentation](https://www.boost.org/doc/libs/1_65_1/libs/test/doc/html/index.html) |
10 | 9 | Davide Pesavento | * After compiling the test binary (or binaries), it is possible at run time to select which tests to run and what kind of output is desired. |
11 | 12 | Davide Pesavento | Use the `--help` command line option to get more information about the available options. |
12 | 2 | Junxiao Shi | |
13 | ## Testing Code Guidelines |
||
14 | 1 | Junxiao Shi | |
15 | 9 | Davide Pesavento | * The test suite for `.../folder/module-name.hpp` should be placed in `tests/.../folder/module-name.t.cpp`. |
16 | 5 | Junxiao Shi | * For example, test suite for `daemon/fw/forwarder.hpp` should be place in `tests/daemon/fw/forwarder.t.cpp`. |
17 | 9 | Davide Pesavento | * The test suite should be named `TestModuleName`, and nested under test suites named after directories. |
18 | 6 | Junxiao Shi | * For example, test suite for `security/transform/base64-decode.hpp` is named `Security/Transform/TestBase64Decode`. |
19 | 9 | Davide Pesavento | * The test suite should be declared inside the same namespace of the tested type plus additional `tests` namespace. |
20 | 5 | Junxiao Shi | * For example, test suite for `nfd::Forwarder` is declared in `nfd::tests`, test suite for `nfd::cs::Cs` is declared in `nfd::cs`. |
21 | * If needed, parent `tests` sub-namespace can be imported with `using namespace` directive. |
||
22 | 10 | Davide Pesavento | * All test suites for the `nfd` binary itself (i.e., for translation units located under `daemon/` subdir) should use the `GlobalIoFixture` fixture, to get automatic setup and teardown of the global `io_service` instance. Other test suites (e.g., for translation units under `tools/` subdir) must not use `GlobalIoFixture`. |
23 | 11 | Davide Pesavento | * Similarly, if a custom fixture is needed for a test suite or test case in `daemon/`, that fixture should derive, directly or indirectly, from `GlobalIoFixture`. |
24 | 10 | Davide Pesavento | * `KeyChainFixture` should be used if a test case needs to create identities in KeyChain. |
25 | * `ClockFixture` or `GlobalIoTimeFixture` can be used if mocked clocks are desired. |
||
26 | 3 | Junxiao Shi | |
27 | ## Testing Helpers |
||
28 | 1 | Junxiao Shi | |
29 | 9 | Davide Pesavento | * `tests/daemon/limited-io.hpp` provides operation count and time limit |
30 | 3 | Junxiao Shi | * `tests/daemon/face/dummy-face.hpp` provides a `Face` that doesn't depend on a socket |
31 | 4 | Junxiao Shi | * `tests/daemon/fw/strategy-tester.hpp` provides a facade to test a forwarding strategy |
32 | 5 | Junxiao Shi | * `tests/daemon/fw/topology-tester.hpp` provides facilities to test forwarder and strategy in a virtual topology |