<div dir="ltr"><div class="gmail_extra">On Wed, Nov 26, 2014 at 12:30 PM, Moskovitz, Bob@DOC <span dir="ltr"><<a href="mailto:Bob.Moskovitz@conservation.ca.gov" target="_blank">Bob.Moskovitz@conservation.ca.gov</a>></span> wrote:<br><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 id=":1er" class="" style="overflow:hidden">This almost sound like the PostGIS Garden Test: <a href="http://trac.osgeo.org/postgis/wiki/DevWikiGardenTest" target="_blank">http://trac.osgeo.org/postgis/wiki/DevWikiGardenTest</a></div></blockquote></div><br></div><div class="gmail_extra">Thanks for the link. This is also a good idea, although I'm not sure how much it is applicable to GRASS GIS modules.<br><br></div><div class="gmail_extra">As they say, it is (close to) monkey testing [1] where you input random data into your algorithms and look if they fail. They get the information about algorithms from documentation. Speaking about modules, we actually have better mechanisms how to get the algorithms and their interfaces (list modules on path or in GUI toolbox). However, this would apply to C and Python interfaces.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Now, I would focus more on the current topic: the tests extracted from examples in documentation. Examples are using the basic functionality and have nice data, so it should not be hard to pass the tests.<br></div><div class="gmail_extra"><br>[1] <a href="http://en.wikipedia.org/wiki/Monkey_test">http://en.wikipedia.org/wiki/Monkey_test</a><br></div></div>