View source for Testing

{{Info|This page is meant for Medusa developers.}}

<figure id="fig:tests">
[[File:tests.png|500px|thumb|upright=2|alt=Output of a successfull ./run_tests.py script run.|<caption>Output of successfull <code>./run_tests.py</code> script run.</caption>]]
</figure>

We have 4 different kind of tests in this library:
* unit tests
* style checks
* documentation checks
* examples

The <code>./run_tests.py</code> script controlls all tests
<syntaxhighlight lang="bash">
usage: run_tests.py [-h] [-c] [-b] [-t] [--build-examples] [-e] [-s] [-d]

Script to check you medusa library.

optional arguments:
  -h, --help          show this help message and exit
  -c, --configure     check your system configuration
  -b, --build         build the library
  -t, --tests         run all tests
  --build-examples    build all examples
  -e, --run-examples  run selected examples
  -s, --style         style checks all sources and reports any errors
  -d, --docs          generate and check for documentation errors
</syntaxhighlight>

Before pushing, always run <syntaxhighlight lang="bash" inline>./run_tests.py</syntaxhighlight>.
This script compiles and executes all tests, checks coding style, documentation and examples. 
If anything is wrong you will get pretty little red error, but if you see green, like in <xr id="fig:tests"/>, 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 [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. 

The basic structure is 
<syntaxhighlight lang="c++">
TEST(Group, Name) {
    EXPECT_EQ(a, b);
}
</syntaxhighlight>

Each header file should be accompanied by a <syntaxhighlight lang="bash" inline><util_name>_test.cpp</syntaxhighlight> with unit tests.

<b>When writing unit tests, always write them thoroughly and slowly, take your time.
Never copy your own code's output to the test; rather produce it by hand or with another trusted tool.
Even if it seems obvious the code is correct, remember that you are writing tests also for the future.
If tests have a bug, it is much harder to debug!</b>

See our examples in [http://e6.ijs.si/medusa/docs/html/examples.html technical documentation].

==Running unit tests==

Tests can be run all at once via <syntaxhighlight lang="bash" inline>make medusa_run_tests</syntaxhighlight> or individually via eg. <syntaxhighlight lang="bash" inline>make operators_run_tests </syntaxhighlight>.

Compiled binary supports running only specified test. Use <syntaxhighlight lang="bash" inline>./bin/medusa_tests --gtest_filter=Domain*</syntaxhighlight> or 
simply <code>GF="Domain" make domain_run_tests</code> for filtering and <syntaxhighlight lang="bash" inline>./bin/medusa_tests --help </syntaxhighlight> for more options.

==Fixing bugs==
When you find a bug in the normal code, fix it and write a test for it. The test should fail before the fix, and pass after the it.

= Style check =
Before committing, a linter <code>cpplint.py</code> is ran on all the source and test files to make sure that the code follows the [[coding style|style guide]].
The linter is not perfect, so if any errors are unjust, feel free to comment appropriate lines in the linter out and commit the change.

= Docs check =
Every function, class or method should also have documentation as enforced by doxygen in the header where they are defined.
In the comment block, all parameters, and return value should be meaningfully described. It can also containing a short example.

Example:
<syntaxhighlight lang="c++">
/**
 * Computes the force that point a inflicts on point b.
 *
 * @param a The index of the first point.
 * @param b The index of the second point
 * @return The size of the force vector from a to b.
 */
double f (int a, int b);
</syntaxhighlight>

Any longer discussions about the method used or long examples belong to this wiki, but can be linked from the docs.

= Continuous build =
We use GitLab Runner, an open source project that is used to run your jobs and send the results back to GitLab. It is used in conjunction with GitLab CI, the open-source continuous integration service included with GitLab that coordinates the jobs.

[https://docs.gitlab.com/runner/#features Runner features]

To configure runner that perform MM test on each commit edit <code>.gitlab-ci.yml</code> in repository.