Skip to content

making tests

Hugo Brunie edited this page Sep 10, 2021 · 2 revisions

We use Catch2 which has pretty good tutorial and reference documentation. Really though, the infrastructure is already set up within the ASGarD project, so maybe the simplest thing to do is to mimic some of the already present tests contained in src/*_tests.cpp.

All tests go along with the component that they are testing, so the tests for a "transforms" component would go into a file called src/transforms_tests.cpp. This will allow CMake to pick up and compile the tests automatically.

Golden data

The issue of how to generate the "known to be good" answers for your unit tests can be tricky sometimes. Ideally, they would come from known truths, such as the a mathematical formula. As a fallback, some of our tests verify that the C++ code reproduces the answers that we get from our prototyping Matlab implementation. These scripts go into testing/scripts and generate .dat files containing the golden data that are read directly by the unit tests.

(FIXME add explanation of auto-generated dat files, the directory structure, and artifact tracking)

So, as a general rule, if the values come from an independent formula (e.g. matrix multiplication), having the golden data hard-coded into the unit test is acceptable. Otherwise, we need an independent record (e.g. a runnable .m matlab/octave file) of how the golden values were generated.

What are we currently testing?

  • time_advance-tests Adaptivity and time advance general methods are tested. The goal is to check first that for certain test cases, the result are the same as the golden ones. Second, that for these same cases, the simulated solution is not too far away from the analytical one. Except for the fokkerplanck_2d for which we do not have an analytical solution.
Clone this wiki locally