[GRASS-dev] Testsuite script v.generalize

[Markus Neteler]

(I have taken liberty to rename the subject - otherwise this gets lost)

Vaclav, can you please move your useful instructions to the documentation?

thanks
Markus

On Wed, Jan 21, 2015 at 3:54 AM, Vaclav Petras <wenzeslaus at gmail.com> wrote:
> On Tue, Jan 20, 2015 at 5:08 PM, Markus Metz <markus.metz.giswork at gmail.com>
>> On Sat, Jan 17, 2015 at 10:21 PM, Vaclav Petras <wenzeslaus at gmail.com>
>> > On Sat, Jan 17, 2015 at 2:40 PM, Markus Metz
>> >> On Fri, Jan 16, 2015 at 11:25 PM, Vaclav Petras <wenzeslaus at gmail.com>
>> >> > On Fri, Jan 16, 2015 at 10:01 AM, Markus Metz
>> >> >> 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
>> >
>> >