<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-10-06 21:26 GMT+02:00 Markus Metz <span dir="ltr"><<a href="mailto:markus.metz.giswork@gmail.com" target="_blank">markus.metz.giswork@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="gmail-">On Tue, Oct 4, 2016 at 11:02 PM, Sören Gebbert<br>
<<a href="mailto:soerengebbert@googlemail.com">soerengebbert@googlemail.com</a>> wrote:<br>
><br>
><br>
> 2016-10-04 22:22 GMT+02:00 Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a><wbr>>:<br>
>><br>
</span><span class="gmail-">>> Recently I fixed bugs in r.stream.order, related to stream length<br>
>> calculations which are in turn used to determine stream orders. The<br>
>> gunittest did not pick up 1) the bugs, 2) the bug fixes.<br>
<br>
</span>sorry for the confusion, r.stream.order does not have any testsuite,<br>
only v.stream.order has.<br>
<span class="gmail-"><br>
>><br>
>> I agree, for tests during development, not for gunittests.<br>
>><br>
>> From the examples I read, gunittests expect a specific output. If the<br>
>> expected output (obtained with an assumed correct version of the<br>
>> module) is wrong, the gunittest is bogus. gunittests are ok to make<br>
>> sure the output does not change, but not ok to make sure the output is<br>
>> correct. Two random examples are r.stream.order and r.univar.<br>
><br>
><br>
> I don't understand your argument here or i have a principal problem in<br>
> understanding the test topic.<br>
><br>
> You have to implement a test that checks for correct output, this is the<br>
> meaning of a test.<br>
<br>
</span>Exactly. During development, however, you need to run many more tests<br>
until you are confident that the output is correct. Then you submit<br>
the changes. My point is that modules need to be tested thoroughly<br>
during development (which is not always the case), and a testsuite to<br>
make sure that the output matches expectations is nice to have. In<br>
most cases,<br></blockquote><div><br></div><div>Implement all tests while developing a module as gunittests and you will have</div><div>a testsuite in the end. You have to implement the tests anyway, so why not using gunittests from the beginning,</div><div>as part of the development process?</div><div><br></div><div>If you implement a Python library, then use doctests to document and check functions and classes while</div><div>developing them. These doctests are part of the documentation and excellent examples howto use</div><div>a specific function or class. And by pure magic, you will have a testsuite in the end.</div><div>Have a look at PyGRASS, tons of doctests that are code examples and validation tests</div><div>at the same time. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<module_name> <args><br>
if [ $? -ne 0 ] ; then<br>
  echo "ERROR: Module <module_name> failed"<br>
  exit 1<br>
fi<br>
<br>
should do the job<br></blockquote><div><br></div><div>Nope. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
no offence :-;<br>
<span class="gmail-"><br>
> You have to design a test scenario from which you know<br>
> what the correct solution is and then you test for the correct solution.<br>
> What is with r.univar? Create a test map with a specific number of cells<br>
> with specific values and test if r.univar is able to compute the correct<br>
> values that you have validated by hand.<br>
><br>
> -- what is the mean, min and max of 10 cells each with value 5? Its 5! --<br>
<br>
</span>what is the correct standard deviation? sqrt((1/n) * SUM(x - mu)) or<br>
sqrt((1/(n - 1)) * SUM(x - mu))?<br>
<br></blockquote><div>If you decide to use the first version, then implement tests for the first version.</div><div>If you decide to use the second version, then ... .</div><div>If you decide to support both versions, then implement tests for both versions.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
r.univar uses sqrt((1/n) * SUM(x - mu)) but sqrt((1/(n - 1)) * SUM(x -<br>
mu)) might be more appropriate because you could argue that raster<br>
maps are always a sample. Apart from that, r.univar uses a one-pass<br>
method to calculate stddev which is debatable.<br></blockquote><div><br></div><div>If you decide to implement a specific version of stddev, then write a test for it.</div><div>Debating which version is more appropriate has nothing to do with the actual software development process.</div><div><br></div><div>Best regards</div><div>Soeren</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Markus M<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
><br>
> The most simple check for that is the raster range check in gunittest. If<br>
> you know what the range of the resulting raster map has to be, then you can<br>
> test for it. If this is not enough then you can check against the<br>
> uni-variate statistic output of the raster map, since you know for sure what<br>
> the result is for min, mean, median, max and so on. If this is not<br>
> sufficient use r.out.ascii and check against the correct solution that you<br>
> have created beforehand. If this is not sufficient then use pygrass and<br>
> investigate each raster cell of the resulting output map.<br>
><br>
> Best regards<br>
> Soeren<br>
><br>
>><br>
>> Markus M<br>
>><br>
>> ><br>
>> > Best regards<br>
>> > Soeren<br>
>> ><br>
>> >><br>
>> >> my2c<br>
>> >><br>
>> >> Markus M<br>
>> >><br>
>> >> ><br>
>> >> > Best<br>
>> >> > Sören<br>
>> >> ><br>
>> >> >><br>
>> >> >> One thing we could think about is activating the toolbox idea a bit<br>
>> >> >> more<br>
>> >> >> and creating a specific OBIA toolbox in addons.<br>
>> >> >><br>
>> >> >>> Identified candidates could be added to core once they fulfill the<br>
>> >> >>> requirements above. Would that happen only in minor releases or<br>
>> >> >>> would<br>
>> >> >>> that also be possible in point releases?<br>
>> >> >><br>
>> >> >><br>
>> >> >> Adding modules to core is not an API change, so I don't see why they<br>
>> >> >> can't<br>
>> >> >> be added at any time. But then again, having a series of new modules<br>
>> >> >> can be<br>
>> >> >> sufficient to justify a new minor release ;-)<br>
>> >> >><br>
>> >> >>> Or is that already too much formality and if someone wishes to see<br>
>> >> >>> an<br>
>> >> >>> addon in core that is simply discussed on ML?<br>
>> >> >><br>
>> >> >><br>
>> >> >> Generally, I would think that discussion on ML is the best way to<br>
>> >> >> handle<br>
>> >> >> this.<br>
>> >> >><br>
>> >> >> Moritz<br>
>> >> >><br>
>> >> >><br>
>> >> >> ______________________________<wbr>_________________<br>
>> >> >> grass-dev mailing list<br>
>> >> >> <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
>> >> >> <a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/grass-dev</a><br>
>> >> ><br>
>> >> > ______________________________<wbr>_________________<br>
>> >> > grass-dev mailing list<br>
>> >> > <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
>> >> > <a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/grass-dev</a><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>