Toggle menu
71
399
28
3.6K
Medusa: Coordinate Free Meshless Method implementation
Toggle preferences menu
Toggle personal menu
Not logged in
Your IP address will be publicly visible if you make any edits.

Testing: Difference between revisions

From Medusa: Coordinate Free Meshless Method implementation
No edit summary
No edit summary
Line 1: Line 1:
We have 4 different kind of tests in this library:
* unit tests
* style checks
* docs check
* system configuration check
The <code>./run_tests.sh</code> script controlls all tests
<syntaxhighlight lang="bash" line>
Usage: ./run_tests.sh
Options:
  -c  run only configuration test
  -t  run only unit tests
  -s  run only stylechecks
  -d  run only docs check
  -h  print this help
Example:
./run_tests.sh -sd
</syntaxhighlight>
Before pushing run <syntaxhighlight lang="bash" inline>./run_tests.sh</syntaxhighlight>.
This script makes and executes all  <syntaxhighlight lang="bash" inline> <util_name>_test.cpp </syntaxhighlight> 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.
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 [https://github.com/google/googletest Google Test framework] for our unit tests. See their [https://github.com/google/googletest/blob/master/googletest/docs/Primer.md introduction to unit testing] for more details.


=Basic usage=
==Running unit tests==


Tests can be run all at once via make
Tests can be run all at once via make
Line 21: Line 60:
This script makes and executes all  <syntaxhighlight lang="bash" inline> <util_name>_test.cpp </syntaxhighlight> test files, checks coding style and
This script makes and executes all  <syntaxhighlight lang="bash" inline> <util_name>_test.cpp </syntaxhighlight> test files, checks coding style and
documentation. You can check them separately as well.
documentation. You can check them separately as well.
<syntaxhighlight lang="bash" line>
Usage: ./run_tests.sh
Options:
  -c  run only configuration
  -t  run only tests
  -s  run only stylechecks
  -d  run only docscheck
  -h  print this help
Example:
./run_tests.sh -sd
</syntaxhighlight>


If anything is wrong you will get pretty little red error, but if you see green, you're good to go.
If anything is wrong you will get pretty little red error, but if you see green, you're good to go.
=Philosophy behind testing=
TO DO: JURE

Revision as of 15:14, 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

Usage: ./run_tests.sh
Options:
  -c   run only configuration test
  -t   run only unit tests
  -s   run only stylechecks
  -d   run only docs check
  -h   print this help
Example:
 ./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.

Running unit tests

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

Each header file should be accompanied by a <util_name>_test.cpp with examples for all functionalities and unit tests.

Tests are written in Google test framework:

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

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

Before pushing run ./util/run_tests.sh. This script makes and executes all <util_name>_test.cpp test files, checks coding style and documentation. You can check them separately as well.

If anything is wrong you will get pretty little red error, but if you see green, you're good to go.