|
|
|
**Page author:** @pineapple
|
|
|
|
|
|
|
|
Unit-tests are an **ESSENTIAL** part of any codebase to assert the behaviour of a new feature and the consequences of any modification in the codebase. Any piece of production code that is not covered by a unit-test will probably later lead to a longer debug session or worse: undetected bad/undefined behaviours.
|
|
|
|
|
|
|
|
## Structure of tests
|
|
|
|
|
|
|
|
Each Aidge module can be supplemented by a test directory called ``unit_tests`` with the following hierarchy:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
unit_tests/
|
|
|
|
|__<any_sub_dir_name_1>/
|
|
|
|
| |__<any_file_name>
|
|
|
|
| |...
|
|
|
|
|__<any_sub_dir_name_2>/
|
|
|
|
|
|
|
|
|
...
|
|
|
|
|__CMakeLists.txt
|
|
|
|
```
|
|
|
|
|
|
|
|
An example of `CMakeLists.txt` file can be found in aidge_core module [here](https://gitlab.eclipse.org/eclipse/aidge/aidge_core/-/blob/main/unit_tests/CMakeLists.txt?ref_type=heads)
|
|
|
|
|
|
|
|
## Writing a test file
|
|
|
|
|
|
|
|
Aidge unit-tests are performed with the C++ test framework [Catch2](https://github.com/catchorg/Catch2).
|
|
|
|
|
|
|
|
A typical test file has the following structure:
|
|
|
|
|
|
|
|
```cpp
|
|
|
|
TEST_CASE("test_title", "[tag1][tag2]...[tagN]") {
|
|
|
|
...
|
|
|
|
SECTION("section1_title") {
|
|
|
|
...
|
|
|
|
}
|
|
|
|
SECTION("section2_title") {
|
|
|
|
...
|
|
|
|
SECTION("secton2_1_title") {
|
|
|
|
REQUIRE(<true_false_statement>)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
There can be any number of TEST_CASE and SECTION as you want. `[tag1][tag2]...[tagN]` are tag declaration for individual tests calls that we'll see later.
|
|
|
|
|
|
|
|
You can add assertions in your tests that should fail and stop the execution (or not) if the program behaviour is not as expected. You can find every assertions available on the official Catch2 [documentation](https://github.com/catchorg/Catch2/blob/devel/docs/tutorial.md). Here are some examples:
|
|
|
|
- `REQUIRE(<true_false_statement>)`
|
|
|
|
- `REQUIRE_THROWS(...)`
|
|
|
|
- `REQUIRE_NOTHROW(...)`
|
|
|
|
- ...
|
|
|
|
|
|
|
|
|
|
|
|
## Compiling unit-tests
|
|
|
|
|
|
|
|
On Unix-based systems, unit-tests can be compiled using the ``setup.sh`` file left at your disposal at the root of the Aidge project. Simply add the optional flag `--tests` (or `-t`) to your compilation command.
|
|
|
|
|
|
|
|
e.g I want to compile the unit-tests of Aidge core, CPU bakcned and CUDA backend. I will run
|
|
|
|
```bash
|
|
|
|
<path_to_aidge>/setup.sh -m core -m backend_cpu -m backend_cuda --tests
|
|
|
|
```
|
|
|
|
|
|
|
|
Every available test in these modules will be compiled, stored in `<path_to_aidge>/aidge/<module_name>/build_bundle_cpp/unit_tests/tests_<module_name>`and run.
|
|
|
|
|
|
|
|
## Running unit-tests
|
|
|
|
|
|
|
|
Once the test binary file has been created with the latest command, you can run it or select and run individual unit-tests with optional flags to alter the output.
|
|
|
|
|
|
|
|
- Select individual TEST_CASE using their user-defined tags
|
|
|
|
```bash
|
|
|
|
<path_to_bin>/tests_<module_name> [tag1][tag34]
|
|
|
|
```
|
|
|
|
- Specify a seed for the random sumber generator ([here](https://github.com/catchorg/Catch2/blob/devel/docs/command-line.md#specify-a-seed-for-the-random-number-generator))
|
|
|
|
- Time your functions with the [BENCHMARK macro](https://github.com/catchorg/Catch2/blob/devel/docs/benchmarks.md)
|
|
|
|
|
|
|
|
Every option for test call can be found on the [command line page](https://github.com/catchorg/Catch2/blob/devel/docs/command-line.md) |
|
|
\ No newline at end of file |