[GRASS-dev] Weekly report 8: Testing framework for GRASS GIS

[Vaclav Petras]

On Sat, Jul 12, 2014 at 7:55 AM, Sören Gebbert <soerengebbert at googlemail.com
> wrote:

> Hi Vaclav,
>
> Very nice progress indeed.
>
>
> > 3. Are you blocked on anything?
> >
> > I did not solved the issue of distribution of tests for different
> platforms.
> > On Unix-like systems (+- Mac OS X), I suppose that all people wanting to
> > test will be able to compile GRASS and download all locations they are
> > interested in. There should be some rule in makefiles to build the C test
> > modules, so that testing framework does not have to deal with that.
> However,
> > doing this on MS Windows is not likely.
>
> Do we have to treat windows C-module tests differently? IMHO all
> C-tests should compile on windows as well? Or is this more a problem
> of how to call such test modules on windows?
>
> 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.


> > Perhaps some special package with
> > GRASS source code including testsuite directories, C test modules'
> binaries
> > and locations would be the way to go.
>
> I have added the raster3d test C-module to the library directory
> Makefile, so it will be compiled by default when all libraries are
> build.


Compiled by default and added to all standard modules [1]? Do we want to
have `test.*` 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.

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.

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.

In addition i added a raster3d library gunittest that calls the
> C-module (r61242). The new gunittest is located in
> lib/raster3d/testsuite and works with direct Python command line call
> and grass.gunittest.main invocation.
>
> Yes, this is the right approach. Call the C module from the gunittest test
file [2].

[1]
http://trac.osgeo.org/grass/browser/grass/trunk/lib/raster3d/test/Makefile?rev=61242
[2]
http://trac.osgeo.org/grass/browser/grass/trunk/lib/raster3d/testsuite/raster3d_lib_test.py?rev=61242

If you think that this approach is meaningful then i will write
> something similar for gmath, gpde, vector rtree and dbmi library
> tests.
>
> Best regards
> Soeren
>
> > Vaclav
> >
> > Src:
> >
> http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/gunittest?rev=61238
> > Wiki:
> >
> http://trac.osgeo.org/grass/wiki/GSoC/2014/TestingFrameworkForGRASS#Week08
> >
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140712/dcd19fe6/attachment.html>