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

[Nikos Alexandris]

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.

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