On Mon, Nov 30, 2015 at 3:27 AM, Jachym Cepicky <[email protected]> wrote:
> about the tests - generally yes, I'm writing it. Are you referring to > r3.info or to g.search.* modules? I could not found any example to > r3.info tests > I meant r3.info as it is more critical but g.search.* is similar just not critical. https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html#tests-of-grass-modules https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/testsuite/test_r_mapcalc.py#L80 https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/gunittest/testsuite/test_assertions.py > > I've rewritten r3.info so that the code is the same, as r.info (with -e > flag) - but I can not tell, I'm satisfied with the result > I also cannot tell. https://trac.osgeo.org/grass/changeset/66983 https://trac.osgeo.org/grass/changeset/66984 > (there are line breaks and quotes in the strings, what IMHO is really not > good) > The comments, history or whatever it is is written as shell command for r and r3, so the strings are in quotes (to be general) and long lines are broken and continuation is done by backslash. With r3.info I now get: comments="r3.flow input="test1" flowaccumulation="test2" unit="cell" step=0.25\ limit=2000 max_error=1e-5 direction="down"" I'm not sure how exactly this compares to r.info. Vectors have this in some better way but it's part of the format and I'm not familiar with it. > My time resources allocatable to this task are slowly reaching to their > end. I would need clear decision from you guys (since you are in charge to > mess around GRASS code base): > > Where to put print_output & supporting functions? > print_output can go to lib/python/script/utils.py (grass.script.utils). The others probably too, although I would mark them as experimental (not guaranteed API). > Where to write tests for them? > In a file in the testsuite directory at the level of the tested file, i.e. lib/python/script/testsuite for lib/python/script/utils.py. (I assume standard unittest package is being used) > unittest and grass.gnunittest, please see https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html > Can I omit g.search.data for now? (I would like to put some better code > structure, as I can see it more clear now) - so I would put only > g.search.module for now to GRASS trunk? > Sure. Thanks! I'm looking forward to it.
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
