<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 4, 2016 at 4:55 PM, Anna Petrášová <span dir="ltr"><<a target="_blank" href="mailto:kratochanna@gmail.com">kratochanna@gmail.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>[...] <br></div></blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div class="gmail-a3s gmail-aXjCH gmail-m157917b4fe0b7199" id="gmail-:1cp">c) test correctness of results.<br>
It just depends how you write them, and yes, for some modules c) is<br>
more difficult to implement than for others.</div></blockquote></div><br><div class="gmail_quote">On Thu, Oct 6, 2016 at 5:00 PM, Anna Petrášová <span dir="ltr"><<a href="mailto:kratochanna@gmail.com" target="_blank">kratochanna@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-:1kc" class="gmail-a3s gmail-aXjCH gmail-m1579bccee97e833d">There is correct result in the sense "as author intended". So you can<br>
use pen and paper and solve very small example. That doesn't mean it<br>
will cover all options, but better than nothing. [...]<br></div></blockquote></div><br><div class="gmail_extra">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.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">This is the original test:<br></div><div class="gmail_extra"><br><a href="https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.forestfrag/testsuite/r_forestfrag_trivial.py">https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.forestfrag/testsuite/r_forestfrag_trivial.py</a><br><br></div><div class="gmail_extra">This is the r.mapcalc bug:<br><br><a href="https://trac.osgeo.org/grass/ticket/3067">https://trac.osgeo.org/grass/ticket/3067</a><br><br></div><div class="gmail_extra">And this is test which specifically shows the bug (would show if it would be reintroduced):<br></div><br><a href="https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/testsuite/test_row_above_below_bug.py">https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/testsuite/test_row_above_below_bug.py</a><br><br></div></div>