On Wed, Jan 21, 2015 at 3:54 AM, Vaclav Petras <wenzesl...@gmail.com> wrote: > > > On Tue, Jan 20, 2015 at 5:08 PM, Markus Metz <markus.metz.gisw...@gmail.com> > wrote: >> >> On Sat, Jan 17, 2015 at 10:21 PM, Vaclav Petras <wenzesl...@gmail.com> >> wrote: >> > >> > >> > On Sat, Jan 17, 2015 at 2:40 PM, Markus Metz >> > <markus.metz.gisw...@gmail.com> >> > wrote: >> >> >> >> On Fri, Jan 16, 2015 at 11:25 PM, Vaclav Petras <wenzesl...@gmail.com> >> >> wrote: >> >> > On Fri, Jan 16, 2015 at 10:01 AM, Markus Metz >> >> > <markus.metz.gisw...@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@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 >> fi >> > Done in r64269 [1].
Thanks. > 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.) It tests some library things and just uses v.generalize to do modifications, thus putting it in lib/vector is fine. Markus M > > 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 >> > >> > > > _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev