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

[Moritz Lennert]

On 06/10/16 23:34, Vaclav Petras wrote:
> On Tue, Oct 4, 2016 at 4:55 PM, Anna Petrášová <kratochanna at gmail.com
> <mailto:kratochanna at gmail.com>> wrote:
>
>     [...]
>
>     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.
>
>
> On Thu, Oct 6, 2016 at 5:00 PM, Anna Petrášová <kratochanna at gmail.com
> <mailto:kratochanna at gmail.com>> wrote:
>
>     There is correct result in the sense "as author intended". So you can
>     use pen and paper and solve very small example. That doesn't mean it
>     will cover all options, but better than nothing. [...]
>
>
> For r.forestfrag, I wrote a test which was based on an example in the
> original paper which was computing value of one cell in 3x3 window. It
> is a really trivial example which tests 1 number and two other numbers
> which are intermediate results. However, by writing it, I actually
> discovered that although the results for a large area look good, this
> small example, which I was able compute by hand, is failing. After
> investigation, it turned out that the error is actually in r.mapcalc.
> Computing the result outside of GRASS was crucial in this case. It was
> an index and I was able to compute it by hand (and check it with the
> example in the paper). For some other modules it could be more difficult
> and I don't want to compute it without GRASS for more than one cell even
> in this case, but it was certainly possible to write a test of
> correctness for this module. Note that the test doesn't show if the
> (forest fragmentation) index makes sense or if it is useful, but it
> shows that the module gives the result it promised.
>
> This is the original test:
>
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.forestfrag/testsuite/r_forestfrag_trivial.py

Nice example, thanks !

>
> This is the r.mapcalc bug:
>
> https://trac.osgeo.org/grass/ticket/3067
>
> And this is test which specifically shows the bug (would show if it
> would be reintroduced):
>
> https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/testsuite/test_row_above_below_bug.py

Here we have an example of a test with 70 lines of code which was 
comitted almost at the same time as the issue was fixed (ok 3 days 
before), with a one-line fix. Now, it's good to safeguard against this 
bug reappearing, but I would argue that this example shows that we often 
only think of relevant tests after a bug appears, and I'm not sure that 
it is very efficient to write a test at that point, given the low 
probability of that bug reappearing ;-)

But hey, bear with me, I'm learning...

Moritz