<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 26, 2014 at 10:44 AM, Markus Neteler <span dir="ltr"><<a href="mailto:neteler@osgeo.org" target="_blank">neteler@osgeo.org</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">Hi,<br>
<br>
in the recent past I added a series of examples to various manual<br>
pages. Most of them might qualify for (basic) testing of the<br>
respective command.<br></blockquote><div><br><div>I totally agree. I have the same idea in my mind for some time and I would really like to see use it but I had no time to implement it.<br></div><br>For
 basic functionality can be implemented quite simply since the testing 
framework supports bash/sh files. You extract the code from the manual 
page into a .sh file, put all these files into proper  directories (the 
are more options what proper is), and then you can run test running 
script on this directory structure instead of the source code. However, 
this approach will not work on MS Windows but there are some possible 
adjustments (for example, different language tabs and/or (limited) 
automatic conversion [1]).<br><br>What is the challenge and what 
requires some thinking is how to test the results and what to do with 
d.* commands. Not test the results and remove d.* commands seems like a 
good option for start.<br><br>This would be a nice analogy to Python 
doctest which also points us towards the fact that main purpose of this 
(and doctest) should be testing of documentation rather then using 
documentation for testing (or instead of testing). In other words, I 
think that purpose of this is to find out if the examples are still 
valid (modules and options exist and map names are not wrong). As a 
bonus this will test if the module starts and in some cases it might 
test if the expected maps were created.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Since it is a bit time consuming to write these standard tests<br>
manually, would there be a chance to develop a test case generator<br>
e.g. driven by a template?<br>
<br></blockquote>Can you tell more about your idea? It seems much more advanced than the basic approach I'm suggesting.<br></div><div class="gmail_quote"><div><br></div><div>Thanks for bringing this up,<br></div><div>Vashek<br></div><div><br>[1] <a href="http://fatra.cnr.ncsu.edu/temporal-grass-workshop/">http://fatra.cnr.ncsu.edu/temporal-grass-workshop/</a><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Markus<br>
_______________________________________________<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" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</blockquote></div><br></div></div>