(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@gmail.com> wrote:
On Tue, Jan 20, 2015 at 5:08 PM, Markus Metz <markus.metz.giswork@gmail.com>
On Sat, Jan 17, 2015 at 10:21 PM, Vaclav Petras <wenzeslaus@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@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@PERMANENT
r.to.vect in=landuse96_28m@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
fiDone 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 ncThis 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.shRunning 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#L148The 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
>
>