<div dir="ltr"><div>1. What did you get done this week?<br><br>I've finally closed #2105 which partially stands behind this GSoC. I used my last comment there to evaluate what I've done in GSoC using the requirements which resulted from the ticket.<br>


<br></div>I've fixed report generation which was broken for the edge case when no test is executed because of error during set up phase.<br><div><br>There were two days without tests when report generation failed due to the fact that number of executed tests from one file was zero. This is fixed and the commit causing no tests to be executed (as well as the current number of failing tests) was reverted.<br>


<br></div><div>As I expected, I was not able to polish code or documentation but documentation is pretty much ready to use and the code is almost fully documented and has tests.<br></div><div><br></div><div>Finally, during writing this email, I decided to implement a new feature, shell scripts can be now used as test files.<br>

</div><div><br>Before using shell scripts, there was currently 11 successfully running test files and 18 failing
 test files, 4 successfully running testsuites and 12 failing 
testsuites, and 709 successfully running tests and 61 failing tests (510
 of the tests are from PyGRASS module test).</div><div><br>2. What do you plan on doing next week?<br><br>Next week no coding should be done for GSoC. Instead, the final evaluation should be submitted. I also plan to prepare code for submission to Google.<br>


<br></div><div>If time allows, I will also write down a TODO list or Final thoughts and create a new page for testing (and mark the GSoC one as read only).<br></div><div><br>3. Are you blocked on anything?<br><br></div><div>


Not for me, but for GRASS the blocker is still the lack of tests. There is a lot of shell scripts which can be used as test.<br><br>To make creating new tests from old ones simpler, I decided to add a possibility to use shell scripts in place of python scripts.* in other words, a test file can by now .py or .sh. Shell script will be executed using `sh -e -x`. To implemented fast I had to drop some unused features and I made MS Windows compatibility worse but this can be fixed in the future and now we can have more tests which is more useful.<br>

<br></div><div>So, feel free to move shell scripts to testsuite directories (of things they are testing) and you can even create simple tests scripts from documentation.<br><br>However, note that writing a new tests using other things that gunittest is strongly discouraged because only by using gunittest we are able to obtain detailed test results and  (optionally) extent testing by analyses such as valgrind.<br>

<br><br>
</div><div><br>Wiki:  <a href="http://trac.osgeo.org/grass/wiki/GSoC/2014/TestingFrameworkForGRASS#Week12" target="_blank">http://trac.osgeo.org/grass/wiki/GSoC/2014/TestingFrameworkForGRASS#Week12</a><br><br>Daily test results online:  <a href="http://fatra.cnr.ncsu.edu/grassgistests/" target="_blank">http://fatra.cnr.ncsu.edu/grassgistests/</a><br>


<br>Ticket #2105: <a href="http://trac.osgeo.org/grass/ticket/2105" target="_blank">http://trac.osgeo.org/grass/ticket/2105</a><br><br>Shell scripts becoming tests:<br><a href="http://trac.osgeo.org/grass/changeset/61658">http://trac.osgeo.org/grass/changeset/61658</a><br>

<a href="http://trac.osgeo.org/grass/changeset/61653">http://trac.osgeo.org/grass/changeset/61653</a><br><br>* Alternative to that calling a shell script from a Python test file. The 
only condition is that shell script must be in data directory of the 
testsuite and Python file must return a return non-zero if tests failed 
(e.g. using set -e).<br></div></div>