[GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Sören Gebbert]

Hi Nikos,

2016-10-06 1:39 GMT+02:00 Nikos Alexandris <nik at nikosalexandris.net>:

> Apologies for removing all but Soeren's last post.
>
> * Sören Gebbert:
>
>
> I would like to put the GRASS test framework into perspective, since i
>> think that its capabilities are not well known.
>> The gunittest framework is not about unit tests. It was designed to test
>> all aspects of the GRASS development. This framework allows you to:
>>
>> * Implement unit tests for the Python libraries, their mthods and classes
>> * Implement and run doctests in the source code of the Python libraries
>> * Run integration tests for all modules, checking correct output for
>> almost
>> all datatypes in GRASS (raster, vector, 3D raster, space-time datasets,
>> categories, color definitions, stdout, ...). Module tests are IMHO
>> integration tests, since module make use of different library methods and
>> classes and combine them.
>> * Run C-library tests as unit and integration tests. C-library unit and
>> integration tests can either be implemented in C or via ctypes in Python
>> * Run tests on library level, module level or for all libraries and
>> modules
>> in the whole GRASS source tree using a single command, ...
>> * Perform regression tests in dedicated test locations, autimatically
>> triggered by a cronjob or a commit
>> * The framework allows you to run all library unit tests, before module
>> integration tests are performed
>> * It creates temporary mapsest to run without problems in production
>> locations
>> * It logs all tests in detail  and generates easy to inspect HTML output
>> at
>> runtime, so you can check the progress of the tests and its gradually
>> available results
>> * It allows on the fly mapset creation and deletion
>> * It supports temporary region environments
>> * It support user defined test data for input generation and output
>> validation
>>
>> These capabilities allow a wide range of tests to be created, covering
>> most
>> aspects of the GRASS development, with the exception of the GUI.
>> So please no excuses that the gunittest framework is not capable of
>> implementing a test that is required to assure module correctness.
>>
>
> Soeren, could you name some good examples (not to the
> manual/s), some real modules with integrated tests?  I am much in need
> for good code.
>

Some examples:
*******************

C-Code
----------

Unittest for the linear equation solver in gmath library:

https://trac.osgeo.org/grass/browser/grass/trunk/lib/gmath/test/test_solvers.c

Integration test of the groundwater flow module, that make use of many
gmath functions. The result of the simulation is tested against reference
values that are based on literature, see the header of the file:

https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.gwflow/testsuite/validation_7x7_grid.py

Python-Code
-----------------

The PyGRASS unittests are a great example and inspiration for testing:

https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/raster/testsuite

https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/vector/testsuite

Integration tests:

The v.stream.order uses the PyGRASS vector library and implements two
integration tests:

https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.stream.order/testsuite/test_stream_order.py

The temporal module t.rast.univar uses integration tests to validate the
combination of the temporal framework, PyGRASS and the functionality of
r.univar:

https://trac.osgeo.org/grass/browser/grass/trunk/temporal/t.rast.univar/testsuite/test_univar.py

The module t.rast.aggreagte combines the temporal framework, PyGRASS and
r.series. Its functionality is tested in several integration tests:

https://trac.osgeo.org/grass/browser/grass/trunk/temporal/t.rast.aggregate#testsuite

Best regards
Soeren


> By the way, working code does not necessarily mean good code.  And vice
> versa, good code does not mean that it works the way it should.
> Yet, broken but "good" code (cleanly documented, tested as much as
> possible)
> can be easily fixed and probably easier optimised.  Working, though
> poor/uncommented/untested code, is frequently, if not always, a
> big-time-consuming mission.
>
> The question, the way I understand things, is not if and at what extent
> we need tests. GRASS-GIS needs them.
> However, no matter the effort, tests will almost never be complete.-
> That's what I was told by computer scientists, and what I can confirm
> with my minimal experiences by doing, for at least two years now, in a
> dozen of mini-projects.
>
> Rather, the question is how can we bring, most, of the theory of testing
> in to
> reality, put it in real action, beautify GRASS' code, whether core or
> addons.  My understanding is that "our" common understanding is to focus
> in raising the overall quality level, make it easy for some-one to read
> the code, to understand the code almost as if reading simple text, to
> enable
> some-one to improve or adapt a piece of code relatively fast.
>
> Step-by-step.  Nothing is going to change overnight.
> Not to forget, the community is a mixture of members with a high
> diversity degree when looking at coding skills.  Everyone should be
> invited. And everyone is invited. Experienced developers, are asked
> and, with all the respect, (you) carry the responsibility to shed light for
> the newcomers in coding for GRASS-GIS.
>
> Allow me please to reiterate what I have repeated indirectly
> or directly, some times:  please, dear reader/coder/scripter, when you
> write code, no matter what you write, comment your code,
> use longer variable names, don't hesitate to repeat explaining, document
> here and there. Test.  Use assertions in your code, even for simple,
> single functions. Write code that "invites" the reader.
>
> Yes, testing costs a lot of time.  But, if comparing it with the time
> spent afterwards in debugging bad code, therein lies the wish to have
> spent the "less"
> time right in the beginning.
>
> Testing will boldly save big, valuable time.-
> It'll beautify GRASS-GIS and grow the community.
> It'll work for us, not against us.
>
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20161006/26220f27/attachment.html>