Unit Testing¶

NFD requires unit testing for most modules.

NFD uses Boost Unit Test Framework.

Learning Resources for Boost Unit Test Framework¶

• Boost Unit Test Framework documentation
• After compiling the unit-test binary, it is possible at run time to select which tests to run and what kind of output is desired.
  Use --help command line option to get more information about the available options.

Testing Code Guidelines¶

• Test suite for .../folder/module-name.hpp should be placed in tests/.../folder/module-name.t.cpp.
  • For example, test suite for daemon/fw/forwarder.hpp should be place in tests/daemon/fw/forwarder.t.cpp.
• Test suite should be named FolderModuleName.
  • Exception: test suite for a header in top-level folder is named TestModuleName so that unqualified ModuleName still refers to the tested type.
  • For example, test suite for daemon/fw/forwarder.hpp is named FwForwarder, test suite for src/name.hpp is named TestName.
• Test suite should be declared inside the same namespace of the tested type plus additional tests namespace.
  • For example, test suite for nfd::Forwarder is declared in nfd::tests, test suite for nfd::cs::Cs is declared in nfd::cs.
  • If needed, parent tests sub-namespace can be imported with using namespace directive.
• Test suite should use nfd::tests::BaseFixture fixture, to get automatic setup and teardown of global io_service.
  • If a custom fixture is defined for test suite or test case, that custom fixture should derive from BaseFixture.
  • IdentityManagementFixture should be used if a test case needs to create identities in KeyChain.
  • UnitTestTimeFixture should be used if mocked clocks are feasible/desirable.

Testing Helpers¶

• tests/core/limited-io.hpp provides operation count and time limit
• tests/daemon/face/dummy-face.hpp provides a Face that doesn't depend on a socket
• tests/daemon/fw/strategy-tester.hpp provides a facade to test a forwarding strategy
• tests/daemon/fw/topology-tester.hpp provides facilities to test forwarder and strategy in a virtual topology