Revision as of 16:23, 1 November 2016

We have 4 different kind of tests in this library:

• unit tests
• style checks
• docs check
• system configuration check

The ./run_tests.sh script controlls all tests

1 Usage: ./run_tests.sh
2 Options:
3   -c   run only configuration test
4   -t   run only unit tests
5   -s   run only stylechecks
6   -d   run only docs check
7   -h   print this help
8 Example:
9  ./run_tests.sh -sd

Before pushing run ./run_tests.sh. This script makes and executes all <util_name>_test.cpp test files, checks coding style and documentation. If anything is wrong you will get pretty little red error, but if you see green, you're good to go.

Unit tests

All library code is tested by means of unit tests. Unit tests provide verification, are good examples and prevent regressions. For any newly added functionality, a unit test testing that functionality must be added.

Writing unit tests

Every new functionality (eg. added class, function or method) should have a unit test. Unit tests

• assure that code compiles
• assure that code executes without crashes
• assure that code produces expected results
• define observable behaviour of the method, class, ...
• prevent future modifications of this code to change this behaviour accidentally

Unit tests should tests observable behaviour, eg. if function gets 1 and 3 as input, output should be 6. They should test for edge cases and most common cases, as well as for expected death cases.

We are using Google Test framework for our unit tests. See their introduction to unit testing for more details.

The basic structure is

1 TEST(Group, Name) {
2     EXPECT_EQ(a, b);
3 }

Each header file should be accompanied by a <util_name>_test.cpp with unit tests.

Running unit tests

Tests can be run all at once via make run_all_tests or individually via eg. make basisfunc_run_tests.

Compiled binary supports running only specified test. Use ./all_tests --gtest_filter=Domain* for filtering and ./all_tests --help for more options.