[GRASS-dev] GSoC idea: Testing framework

[Vaclav Petras]

On Fri, Jan 31, 2014 at 11:53 AM, Pietro <peter.zamb at gmail.com> wrote:

> On Fri, Jan 31, 2014 at 3:53 PM, Vaclav Petras <wenzeslaus at gmail.com>
> wrote:
> >> I've used doctest to cover some of the pygrass' functions and modules,
> >> but I don't like too much, at the moment to test the pygrass' doctest
> >> you have to be inside the NorthCarolina/user1 location/mapset, that is
> >> not always practical.
> >
> >
> > On the other hand, my impression from writing tests was that sometimes it
> > would be advantageous
> > to have some prepared location with everything, so I would like to go in
> the
> > way of supporting different locations rather then requiring all tests to
> use
> > only data their generate in the preparation phase.
>
> I agree, perhaps we can use the demolocation in the trunk for this purpose?
> May be when we run the tests, the testing framework could set
> everything to run on the demolocation, run the test and then restore
> the previous configuration?
>
> For sure. This is how the compilation works or at least is supposed to
work. But also, I would like test itself to specify in which location(s) it
can run and then run it in these locations.

If you would like to use this now, my very limited knowledge of Makefiles
tells me that you can try to use `run_grass` in Makefile. I've never tried
but according to gui/wxpython/Makefile it should work. Try it outside grass
session. You Makefile should contain something like this

default: $(DSTFILES)
...
-$(MAKE) mytest
mytest:
$(call run_grass,$(PYTHON) myscript.py params)

`make` or `make test` should then run `python myscript.py params` in
demolocation. But as I said it is probably just a theory...


> >> Would be nice to have something that run independently from the
> >> location/mapset. 'm studying the unittest framework and in a short
> >> time I would like to start to write some unittest for the pygrass
> >> library.
> >
> >
> > unittest test which does not rely on location/mapset is probably the
> default
> > and preferred way, so I'm looking forward to see this.
>
> I mean, would be nice to insert this on the GRASS testing framework,
> but I will not work on this.
>
> Do what ever you think is advantageous to you, I will then consider how to
integrate it.

>
> >> I really like it, and they can also help users to move they bash
> >> scripts to python.
> >
> > I used doctest in this way for the first time but it seems that it is as
> > easy as writing bash script and you get doctest functionality and Python
> > functionality to examine your results. The testing framework (perhaps
> > unittest class inside some script) would run the doctest file in the
> right
> > environment (location) or in several environments if desired.
>
> yes, may be not only for the doctest but for everything?
>

If I inferred correctly what you mean the answer is yes. I will explain
this idea further in next days or weeks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140131/fcf1c49a/attachment.html>