<html>
<head>
<meta http-equiv="Content-Type" content="text/html"/>
</head>
<body>
<div style="color: black;">
<p style="margin: 0 0 1em 0; color: black; font-family: sans-serif;"></p>
<p style="margin: 0 0 1em 0; color: black; font-family: sans-serif;">On 7
October 2016 3:14:14 pm "Blumentrath, Stefan"
<Stefan.Blumentrath@nina.no> wrote:</p>
<p style="margin: 0 0 1em 0; color: black; font-family: sans-serif;">>
Hi again,<br>
><br>
> Interesting discussion!<br>
><br>
> With my user and amateur addon-developer perspective I would conclude
that:<br>
> - we all agree that tests/unittests are very useful even if not
"the silver bullet"<br>
> - things one does in "unittests" might also partly be done in the code
of the module (e.g. check for a specific state of input or environment
variables ...), so a requirement for unittest might have to go hand in hand
with a requirement for "maturity" of the module?<br>
> - "unittests" can also differ a lot in complexity so it is probably
not too easy to say which level of unit tests should be required for a new
core module, and the presence of a test alone does not necessarily mean
that a module is "well tested"...<br>
> - it might be a good starting point to "require" only "simple"
unittests for new core modules in that sense that a unit test makes sure
that at least examples from the manual work without throwing an error? That
would at the same time test code and manual/documentation... There was the
idea to use examples from the manual to auto-generate tests, was`nt it?<br>
> - with more tests on "higher level" modules, also
"lower level functions" (e.g. library) might be covered. This could on the
one hand help to trace (side) effect of changes on lower level functions,
but on the other hand might require to also update all output-tests which
were written based on that bogus library function, would not it?<br>
> - like some others here I never wrote a test for my addons, but I
would be willing to learn! </p>
<p style="margin: 0 0 1em 0; color: black;"></p>
<p style="margin: 0 0 1em 0; color: black;">Same here</p>
<p style="margin: 0 0 1em 0; color: black; font-family: sans-serif;">Here
the simple examples Vaclav provided were very helpful, as for me as a
rookie the more involved examples and the full documentation of the
unittests are hard to understand. </p>
<p style="margin: 0 0 1em 0; color: black;"></p>
<p style="margin: 0 0 1em 0; color: black;">Again, same here</p>
<p style="margin: 0 0 1em 0; color: black; font-family: sans-serif;">Maybe
you can add a very minimalistic example to the test documentation that only
checks (e.g. based on NC data set) that e.g. "r.example -g input=mymap"
works without throwing an error?</p>
<p style="margin: 0 0 1em 0; color: black;"></p>
<p style="margin: 0 0 1em 0; color: black;">+1<br>
</p>
<p style="margin: 0 0 1em 0; color: black; font-family: sans-serif;"><br>
><br>
> And finally, Martins request regarding an RFC for
"promoting modules to core" should not drown in the discussion about
unittests (even if the latter probably is a precondition to the former)...<br>
><br>
> Cheers<br>
> Stefan<br>
><br>
> P.S.: For automatized tests of addons there might be a dependency
issue, as a test-server would have to be equipped with all possible
dependencies in order to be able to run the addons?<br>
><br>
><br>
><br>
> -----Original Message-----<br>
> From: grass-dev [mailto:grass-dev-bounces@lists.osgeo.org] On Behalf
Of Moritz Lennert<br>
> Sent: 7. oktober 2016 08:32<br>
> To: Vaclav Petras <wenzeslaus@gmail.com>; Anna Petrášová
<kratochanna@gmail.com><br>
> Cc: GRASS developers list <grass-dev@lists.osgeo.org>; Markus
Metz <markus.metz.giswork@gmail.com><br>
> Subject: Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons
to move to core<br>
><br>
> On 06/10/16 23:34, Vaclav Petras wrote:<br>
>> On Tue, Oct 4, 2016 at 4:55 PM, Anna Petrášová
<kratochanna@gmail.com <br>
>> <mailto:kratochanna@gmail.com>> wrote:<br>
>><br>
>> [...]<br>
>><br>
>> 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.<br>
>><br>
>><br>
>> On Thu, Oct 6, 2016 at 5:00 PM, Anna Petrášová
<kratochanna@gmail.com <br>
>> <mailto:kratochanna@gmail.com>> wrote:<br>
>><br>
>> 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>
>><br>
>><br>
>> For r.forestfrag, I wrote a test which was based on an example in
the <br>
>> original paper which was computing value of one cell in 3x3
window. It <br>
>> is a really trivial example which tests 1 number and two other
numbers <br>
>> which are intermediate results. However, by writing it, I actually
<br>
>> discovered that although the results for a large area look good,
this <br>
>> small example, which I was able compute by hand, is failing. After
<br>
>> investigation, it turned out that the error is actually in
r.mapcalc.<br>
>> Computing the result outside of GRASS was crucial in this case. It
was <br>
>> an index and I was able to compute it by hand (and check it with
the <br>
>> example in the paper). For some other modules it could be more <br>
>> difficult and I don't want to compute it without GRASS for more
than <br>
>> one cell even in this case, but it was certainly possible to write
a <br>
>> test of correctness for this module. Note that the test doesn't
show <br>
>> if the (forest fragmentation) index makes sense or if it is
useful, <br>
>> but it shows that the module gives the result it promised.<br>
>><br>
>> This is the original test:<br>
>><br>
>> <a
href="https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.fore">https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.fore</a><br>
>> stfrag/testsuite/r_forestfrag_trivial.py<br>
><br>
> Nice example, thanks !<br>
><br>
>><br>
>> 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>
>> And this is test which specifically shows the bug (would show if
it <br>
>> would be reintroduced):<br>
>><br>
>> <a
href="https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/test">https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/test</a><br>
>> suite/test_row_above_below_bug.py<br>
><br>
> 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 ;-)<br>
><br>
> But hey, bear with me, I'm learning...<br>
><br>
> Moritz<br>
> _______________________________________________<br>
> grass-dev mailing list<br>
> grass-dev@lists.osgeo.org<br>
> <a
href="http://lists.osgeo.org/mailman/listinfo/grass-dev">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
> _______________________________________________<br>
> grass-dev mailing list<br>
> grass-dev@lists.osgeo.org<br>
> <a
href="http://lists.osgeo.org/mailman/listinfo/grass-dev">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</p>
</div>
</body>
</html>