r2 - 2011-08-23 - 10:55:32 - LinusKarlssonYou are here: NTP >  Dev Web > UnitTestFramework
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p10 was released on 21 March 2017. It addresses 6 medium- and 5 low-severity security issues, 4 informational security topics, 15 bugfixes, and contains other improvements over 4.2.8p9.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

Unit Test Framework

Related Topics: UnitTestingNotes

Required Tools

To make use of the test framework you will need:

Running the tests

If the required tools are available, they will be found by configure and automatically included in the NTP build. The tests are executed as part of make check .

Writing new tests

The tests are located in the tests/libntp/ directory for libntp, and in sntp/tests/ for sntp. There is usually one test file for each tested source file in the distribution.

To add a new test to an already existing test file, the only thing needed is to add a new TEST_F(test_fixture, test_name) { ... } block to the file. Next time make check is invoked, the new test will be compiled and executed together with the other tests.

To add a new test file, put it together with the other tests inside the correct test directory. Since the test framework is written in C++, the test files should have the extension .cpp. Remember to add the test file to Makefile.am, so it is compiled and executed.

Every test file should have at least one text fixture class. The fixture class should inherit from a common base class: libntptest or sntptest for libntp and sntp. Please see the example referenced below, which also contains examples of other base classes.

When writing tests:

  • Keep each test as small as possible. A failed test is more useful if it's possible to see exactly what's wrong.
  • Test fixtures should be granular. If tests aren't related to each other, they should not share the same test fixture. Instead, shared code could be moved to a common base class.

Further documentation about Google Test can be found at: http://code.google.com/p/googletest/wiki/V1_5_Documentation

Test file template

 * This is an example of a test file, and can be used as a template
 * when writing new tests.

 * All tests for a product share a common base class. For libntp this is
 * class libntptest in libntptest.h
 * Tests for sntp would use class sntptest in sntptest.h
 * There are also more specific base classes that helps with certain types of
 * tests:
 * - fileHandlingTest, which is used for tests that read and/or write to disk.
 * - lfptest, which is used to compare l_fp.
 * If some code is shared between multiple text fixtures, it's a good idea
 * to factor the common code out to a new common base class.
#include "libntptest.h"

 * Since the tests are compiled with the C++-compiler it is important that
 * all C-headers or global variables are put inside this extern "C"-statement
 * to avoid linking errors.
extern "C" {
// #include "header_written_in_c.h"
// extern int global_variable;

 * Each test file should have (at least) one text fixture class that inherits
 * from the common base class. The common base class contains functions that
 * all tests can use.
 * The test fixture can be used to perform common initialization code
 * required for each test. Observe that a new instance of this class is
 * created for each test.
 * Test fixtures should be granular, if methods need to be shared between
 * tests it may be better to put shared methods in a common base class instead.
class exampleFileTest : public libntptest {
    * Executed before each test is run. Common examples of code in this
    * function are initialization code that resets the state at the start
    * of each test. This is important since we want all tests to be
    * independent of each other, and therefore the initial state of all
    * tests must be identical.
   virtual void SetUp() {


    * Executed before each test ends. Both SetUp and TearDown can be
    * omitted if they are not required.
   virtual void TearDown() {

    * Member functions and variables can be defined here, and be used in all
    * tests derived from this test fixture.

 * A test is defined by a TEST_F macro, the first parameter is the name
 * of the test fixture class defined above, and the second parameter is the
 * name of the test, which will be shown when the tests are executed
 * by 'make check'.

 * As an example, here is a couple of tests for libntp's atoint()-function.
TEST_F(exampleFileTest, Positive) {
   const char* str = "17";
   long val;

    * Use Google Test's assertion macros to check if the result is
    * as expected. See the documentation of Google Test for a list
    * of possible assertion macros:
    * http://code.google.com/p/googletest/wiki/V1_5_Documentation
   ASSERT_TRUE(atoint(str, &val));

    * Put the expected value as first parameter, and the actual
    * value as the second parameter. This makes the error messages
    * easier to read.
   EXPECT_EQ(17, val);

 * Apart from verifying that tests give the correct result when given valid
 * input, there should also be tests that verify the behaviour for invalid
 * input. In the example below the given input string is bigger than INT_MAX.
TEST_F(exampleFileTest, PositiveOverflow)
   const char *str = "2300000000"; // Bigger than INT_MAX.
   long val;

   EXPECT_FALSE(atoint(str, &val));

 * This was just two small examples, further tests could test that
 * the function works as expected with negative integers, invalid characters
 * in the string etc.
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r2 < r1 | More topic actions
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback