<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 12, 2014 at 7:55 AM, Sören Gebbert <span dir="ltr"><<a href="mailto:soerengebbert@googlemail.com" target="_blank">soerengebbert@googlemail.com</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 Vaclav,<br>
<br>
Very nice progress indeed.<br>
<div class=""><br>
<br>
> 3. Are you blocked on anything?<br>
><br>
> I did not solved the issue of distribution of tests for different platforms.<br>
> On Unix-like systems (+- Mac OS X), I suppose that all people wanting to<br>
> test will be able to compile GRASS and download all locations they are<br>
> interested in. There should be some rule in makefiles to build the C test<br>
> modules, so that testing framework does not have to deal with that. However,<br>
> doing this on MS Windows is not likely.<br>
<br>
</div>Do we have to treat windows C-module tests differently? IMHO all<br>
C-tests should compile on windows as well? Or is this more a problem<br>
of how to call such test modules on windows?<br>
<div class=""><br></div></blockquote><div>We do if we don't want to mix standard and test modules. The compilation is the problem because only few people can compile GRASS on MS Windows from source. Once modules are compiled, it is only a matter of adding the right directory to PATH to invoke them. However, even the other tests are issue since they are not part of the distribution. See details bellow.<br>

</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"><div class="">
> Perhaps some special package with<br>
> GRASS source code including testsuite directories, C test modules' binaries<br>
> and locations would be the way to go.<br>
<br>
</div>I have added the raster3d test C-module to the library directory<br>
Makefile, so it will be compiled by default when all libraries are<br>
build.</blockquote><div><br></div><div>Compiled by default and added to all standard modules [1]? Do we want to have `<span class="">test</span>.*` files on PATH? Maybe just compile by default and add to a separate directory which can be added to PATH during the tests. This might be the most simple solution and not so different from your current solution.<br>

<br></div><div>Also there should be the possibility for packagers to remove all tests. `rm .../bin/test.*` and `rm -r .../testbin` are almost the same, the later is more clear, perhaps.<br><br></div><div>However, C test modules are only part of the problem. The current design is that all tests (test files + their specific data) are only in the source code and their are not part of the distribution (nothing goes to `dist...` directory). I quite like it because tests does not mess the distribution. On the other hand, if they would be in one directory (preferable with the structure of source code directory) they would be easily removable.<br>

</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">In addition i added a raster3d library gunittest that calls the<br>
C-module (r61242). The new gunittest is located in<br>
lib/raster3d/testsuite and works with direct Python command line call<br>
and grass.gunittest.main invocation.<br>
<br></blockquote><div>Yes, this is the right approach. Call the C module from the gunittest test file [2].<br><br>[1] <a href="http://trac.osgeo.org/grass/browser/grass/trunk/lib/raster3d/test/Makefile?rev=61242">http://trac.osgeo.org/grass/browser/grass/trunk/lib/raster3d/test/Makefile?rev=61242</a><br>

[2] <a href="http://trac.osgeo.org/grass/browser/grass/trunk/lib/raster3d/testsuite/raster3d_lib_test.py?rev=61242">http://trac.osgeo.org/grass/browser/grass/trunk/lib/raster3d/testsuite/raster3d_lib_test.py?rev=61242</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">
If you think that this approach is meaningful then i will write<br>
something similar for gmath, gpde, vector rtree and dbmi library<br>
tests.<br>
<br>
Best regards<br>
Soeren<br>
<div class=""><br>
> Vaclav<br>
><br>
> Src:<br>
> <a href="http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/gunittest?rev=61238" target="_blank">http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/gunittest?rev=61238</a><br>
> Wiki:<br>
> <a href="http://trac.osgeo.org/grass/wiki/GSoC/2014/TestingFrameworkForGRASS#Week08" target="_blank">http://trac.osgeo.org/grass/wiki/GSoC/2014/TestingFrameworkForGRASS#Week08</a><br>
><br>
</div>> _______________________________________________<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>