<div dir="ltr">Hi,<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
><br>
> You are very welcome to write the missing tests for core modules.<br>
><br>
> However, i don't understand the argument that because many core modules have<br>
> no tests, therefore new modules don't need them. If developers of addon<br>
> module are serious about the attempt to make their modules usable and<br>
> maintainable for others, then they have to implement tests. Its and integral<br>
> part of the development process and GRASS has a beautiful test environment<br>
> hat makes writing tests easy. Tests and documentation are part of coding and<br>
> not something special. I don't think this is a hard requirement.<br>
><br>
> There is a nice statement that is not far from the truth: Untested code is<br>
> broken code.<br>
<br>
</div></div>these gunittests only test if a module output stays the same. This<br></blockquote><div> </div><div>This is simply wrong, please read the gunittest documentation.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
does not mean that a module output is correct. Tested code means first<br>
of all that the code has been tested with all sorts of input data and<br>
combinations of input data and flags. All these tests, e.g. what I did<br></blockquote><div><br></div><div>The gunittest framework is designed to do exactly that.</div><div>It has plenty of methods to validate the output</div><div>of modules, ranging from key/value validation, over statistical analysis of the output, to md5</div><div>checksum validation for raster, 3D raster, vector and binary/text file output.</div><div>It can test floating point output to a specific precision to avoid rounding errors or to consider the</div><div>variability of a random number based algorithm like random forest or boosted regression trees.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
for i.segment or r.stream.* (where I am not even the main author)<br>
should IMHO not go into a gunittest framework because then running<br>
gunittests will take a very long time. In short, simply adding<br>
gunittests to addon modules is not enough, code needs to be tested<br>
more thoroughly during development than what can be done with<br>
gunittests.<br></blockquote><div><br></div><div>The gunittest for the v.stream.order addon is an example how its done:</div><div><a href="https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.stream.order/testsuite/test_stream_order.py">https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.stream.order/testsuite/test_stream_order.py</a></div><div><br></div><div>You can write gunittests that will test every flag, every option, their combination and any output of a module. I have implemented plenty of tests, that check for correct error handling. Writing tests is effort, but you have to do it anyway. Why not implementing a gunittest for every feature while developing the module? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
My guess for the r.stream.* modules is at least 40 man hours of<br>
testing to make sure they work correctly. That includes evaluation of<br>
float usage, handling of NULL data, comparison of results with and<br>
without the -m flag. Testing should be done with both high-res (LIDAR)<br>
and low-res (e.g. SRTM) DEMs.<br></blockquote><div> </div><div>Tests can be performed on artificial data that tests all aspects of the algorithm. Tests that show the correctness of the algorithm for specific small cases should be preferred. However, large data should not be an obstacle to write a test.</div><div><br></div><div>Best regards</div><div>Soeren</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
my2c<br>
<br>
Markus M<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
><br>
> Best<br>
> Sören<br>
><br>
>><br>
>> One thing we could think about is activating the toolbox idea a bit 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 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 can't<br>
>> be added at any time. But then again, having a series of new modules 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 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 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>
</div></div></blockquote></div><br></div></div>