[GRASS-dev] GSoC idea: Testing framework

[Pietro]

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?


>> 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.


>> 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?