[GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Vaclav Petras]

Hi Nikos,

On Wed, Oct 5, 2016 at 7:39 PM, Nikos Alexandris <nik at nikosalexandris.net>
wrote:

> could you name some good examples (not to the
> manual/s), some real modules with integrated tests?  I am much in need
> for good code.
>

I'm not sure if they are good, but here are some examples based on Anna's
test categories.

On Tue, Oct 4, 2016 at 4:55 PM, Anna Petrášová <kratochanna at gmail.com>
wrote:

> [...]
> gunittests can serve to a) test inputs/outputs b) catch changes in
> results (whether correct or incorrect) c) test correctness of results.
> It just depends how you write them, and yes, for some modules c) is
> more difficult to implement than for others.
>

a) inputs/outputs

This one tests if the outputs are there (module runs, accepts flags, gives
outputs) and if the output values are in expected ranges ("basic
correctness") and the output are expected data types. It also tests some
stats like sum and variance of the result, but that's more for the category
b).

https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.forestfrag/testsuite/r_forestfrag_ncspm.py

b) result changes

This uses a miniature dataset and results obtained by the module itself. It
tests all values of the result and expects them to match the reference.
This will catch a regression in a module code (or in dependencies).

https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.forestfrag/testsuite/r_forestfrag_xy.py

It assumes that the model worked at the point these were obtained. If that
was not the case, the data must be changed like in this commit:

https://trac.osgeo.org/grass/changeset/68722

c) correctness

Here is a test on a miniature example which was possible to compute by hand
and was part of the original publication.

https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.forestfrag/testsuite/r_forestfrag_trivial.py

Here is a test which uses reference data computed using another software:

https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.slope.aspect/testsuite/test_r_slope_aspect.py?rev=68557#L44
https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.slope.aspect/testsuite/data

Using gdaldem to test r.slope.aspect it is actually not ideal, because
gdaldem uses old r.slope.aspect code. So in this case, it is more a test
against very old version of r.slope.aspect.

This is definitively a creative part because you need to get the results
without using the code you are developing to get the result. For example,
if you have prototype implementation in Python or r.mapcalc and then your
write C code to do the same more effectively with more options, you can use
the prototype to cover part of your outputs. This of course does not give a
guarantee that you did not make the same mistake twice, but it is almost
guaranteed that you will make two separate sets of mistakes and this will
expose them.

It of course never hurts to test also the "basic correctness", e.g. that
the values are all positive or that they are from 0 to 255 and are integers.

d) small parts and dependencies

There is one more category I would add to this list. These are the tests of
building blocks (units) you are using in your module. It can be functions
your wrote but also functions or modules you are using. When writing a C
module you can write a separate module which uses the functions from your
module one by one to generate some testable outputs. These output can be
then tested using the gunittest procedure.

https://trac.osgeo.org/grass/browser/grass/trunk/raster3d/r3.flow/test_main.c
https://trac.osgeo.org/grass/browser/grass/trunk/raster3d/r3.flow/testsuite/r3flow_test.py

Further, you can write a ctypes-based (fully) Python test for the library
functions your are using:

https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/testsuite/gis_lib_tokenize.py

For Python modules, you can do the same it is just much easier and Soeren
already provided examples for it.

Hope this helps,
Vaclav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20161006/3f84ff5c/attachment-0001.html>