[GRASS-dev] Planning GRASS GIS 7.0.0RC1

[Vaclav Petras]

On Tue, Jan 20, 2015 at 5:08 PM, Markus Metz <markus.metz.giswork at gmail.com>
wrote:

> On Sat, Jan 17, 2015 at 10:21 PM, Vaclav Petras <wenzeslaus at gmail.com>
> wrote:
> >
> >
> > On Sat, Jan 17, 2015 at 2:40 PM, Markus Metz <
> markus.metz.giswork at gmail.com>
> > wrote:
> >>
> >> On Fri, Jan 16, 2015 at 11:25 PM, Vaclav Petras <wenzeslaus at gmail.com>
> >> wrote:
> >> > On Fri, Jan 16, 2015 at 10:01 AM, Markus Metz
> >> > <markus.metz.giswork at gmail.com> wrote:
> >> >>
> >> >> The fixes are all thoroughly tested (I guess I have never
> >> >> before tested vector topology so thoroughly...).
> >> >
> >> >
> >> > Hi Markus,
> >> >
> >> > will you be able to turn your tests into testsuite scripts? It is
> >> > additional
> >> > work but it gives us possibility to ensure that nobody will break what
> >> > you
> >> > did and it should save it your time in the long run.
> >>
> >> I modified v.generalize in my local copy to become a topology
> >> debugging tool. The debugging tools could be activated with an
> >> environment variable which would need to be set by the test suite.
> >>
> > Setting environmental variable should be easy in the test suite. I'm not
> > sure about the v.generalize modification. Topology debugging tool sound's
> > generally useful. Perhaps it could be part of v.generalize interface or a
> > standalone module (build with v.generalize in the same way as r.colors
> and
> > r3.colors are) but for tests it really doesn't matter.
> >
> >> If I turn the tests into a test suite script, I will use a vector from
> >> the the full version of the North Carolina sample dataset. Is this ok?
> >
> >
> > This is ok. MarkusN says we should use the new dataset but I think it is
> not
> > yet stable.
> >>
> >>
> >> >
> >> > Let me know if you miss something in testing framework which would
> help
> >> > you
> >> > to write the tests.
> >>
> >> I would like to provide a command and the test suite must check the
> >> return status. If someone else could then turn this into a testsuite
> >> script, that would be great!
> >>
> > Any .sh or .py script you put to testsuite directory anywhere in GRASS
> > source code will be executed as test, so in your case, it should be
> enough
> > just to put the command to .sh file together with the appropriate export
> > command for the environmental variable. I'm afraid this feature is not
> > really documented (except for emails) because I did it in last minute
> and it
> > is not the best practice. Anyway, posting command is fine if the only
> thing
> > needed is to check return status.
>
> For nc_spm_08, the test commands would be (as shell script):
>
> g.region -p rast=landuse96_28m at PERMANENT
> r.to.vect in=landuse96_28m at PERMANENT out=landuse96_28m type=area
> export GRASS_VECTOR_TOPO_DEBUG=1
> # check return code of
> v.generalize in=landuse96_28m out=landuse96_28m_dp method=douglas
> threshold=21
> if [ $? -ne 0 ] ; then
>   exit 1
> fi
>
> Done in r64269 [1]. To run, start GRASS and execute [2]:

  cd lib/vector/
  python -m grass.gunittest.main --location
my_nc_spm_08_grass7_location_for_tests --location-type nc

This will create a proper report from all tests in all testsuite
directories inside the tree starting at lib/vector/. Find the report in
testreport/index.html. Alternatively, execute just the script you want:

  cd lib/vector/testsuite/
  sh -e -x test_topology_vgeneralize.sh

Running directly would be possible but you want to set -e flag for failing
on the first non-zero return status as it is done inside testing framework
[3].

I was not really sure what it is testing some library things or the
v.generalize debug feature itself. I though the former, so I put it to
lib/vector. Please, move it somewhere else, if it tests something
different. (Test suite directory should be in the directory with tested
code.)

As I said, shell script is not ideal because it will not work on MS Windows
in GRASS GIS 7 unless you install it but it is at least something.
Rewriting to Python would be better and actually not so difficult if only
plain Python is used but this would still miss the advantages of the
testing framework. Rewriting using gunittest is relatively simple too but I
just don't have time to do that.

Vaclav

[1] http://trac.osgeo.org/grass/changeset/64269
[2]
http://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html#testing-with-gunittest-package-in-general
[3]
http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/gunittest/invoker.py?rev=62358#L148



> The vectors in the sample datasets are "too good", I did not find a
> vector to provoke any errors, thus the r.to.vect step.
>
> Real world datasets, particularly vectors with administrative areas or
> land cover/land use classification, are in this respect more suitable
> because they contain lots of topological errors. Unfortunately, these
> datasets are too large to be included in the sample datasets.
>

Markus M
> >
> > Vaclav
> >
> >> Markus M
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150120/0b9a2953/attachment-0001.html>