[GRASS-dev] Test suite for GRASS - proposal, discussion welcome

GRASS GRASS developer
1

Hi,

By my opinion, sections are not clearly separated in the examples on wiki page.
It will be something like "good practise" to write:

# description of test
# .................
#
#@preprocessing
# ... some comments ....
command1
command2
#
#@test
# .... some comments ....
command3
command4

or alternatively

# ... some commants ...
#@test
commandX

Are you going to introduce annotation @assert('...message...',condition) or something like this?

Regards

Pawel

----- "Soeren Gebbert" <soerengebbert@googlemail.com> napisał:

Hi all,
i have summarized the ideas of Anne, Glynn and me in the wiki:

http://grass.osgeo.org/wiki/Test_Suite

Hopefully most of the ideas a listed there.

While reviewing the g3d library code and related modules i
implemented
prototypes of test cases for several r3.* modules. Some of them are
added as test case code examples to the wiki.

Any comments, suggestions are welcome.

Best regards
Soeren
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

2

Hello Pawel,

2011/6/17 Pawel Netzel <pawel.netzel@uni.wroc.pl>:

Hi,

By my opinion, sections are not clearly separated in the examples on wiki page.

This is intention. IMHO the annotation should be part of the
documentation so the test writer need to formulate sentence using
predefined words.

It will be something like "good practise" to write:

# description of test
# .................
#
#@preprocessing
# ... some comments ....
command1
command2
#
#@test
# .... some comments ....
command3
command4

or alternatively

# ... some commants ...
#@test
commandX

This will work of course too. If its generally accepted to use this
style in the test script we can document and suggest it as "good
practice".

Are you going to introduce annotation @assert('...message...',condition) or something like this?

No, it should be as simple as possible but not too simple. IMHO only
the framework has to take car of the error message generation. In case
special conditions are tested it should be noticed in the test
documentation.

Best regards
Soeren