Test Suite

GRASS Test Suite

We aim at creating a comprehensive test suite for GRASS modules and libraries.

Background

See what has been done so far by Sören Gebbert and others here: Development#QA and the good [| VKT test suite]

Keep an eye on GRASS 7 ideas collection

Main picture

We plan to run unittests and integration tests for both libraries and modules. The test suite will be run after compilation, with a command like:

 $ make tests [ proj ]

Options:

• proj: run the tests with a [list of] CRS, so that reprojection and map unit handling are tested.
• ...

Tests are executed recursively. If the "make tests" command is executed in the root source folder all libraries and modules are tested. To test only the libraries you need to switch in the lib directory and execute "make tests". If you want to test only raster modules switch into the raster directory and run "make tests", same for other modules directories. To test a single module switch into the module directory and run "make tests".

Tests

Modules

Tests are targeted to cover all modules as well as library test modules.

The modules tests should as independent as possible from other GRASS modules.

Tests are written as simple shell script with annotations. Test script should start with test. followed by the module name i.e. r.mapcalc. and further ending with .sh. Example test.r.mapcalc.1.sh. All test should be well documented using shell comments.

The framework will execute all test scripts starting with test. and ending with .sh located in module or library directories.

Annotations are integrated in the test documentation (simple shell comments) and specify pre-processing steps, the tests and the type of the data to validate. The following annotations should be supported:

• The @preprocess annotation
  • All commands below this annotation are handled as preprocessing steps for the tests.
  • If any of the preprocess commands fail, the framework should stop testing an create a detailed error report.
  • Preprocessing steps may be data generation, region settings and so on.
  • The preprocess annotation is valid till a @test annotation specifies the begin of a test
  • Preprocess annotations can be specified at between tests
• The @test annotation
  • All command below a this annotation are handled as tests by the framework
  • The test annotation must be integrated in the comment block which describes the test
  • Data validation is performed by the framework for tests if reference data is present
  • The test annotation is valid till a @preprocess annotation specifies the begin of a preprocess block for further test runs
• The data type annotations
  • Data type annotations should be specified in the same comment block as the @test annotation
  • Data type annotations specify the grass data types which should be validated with reference data
  • The following data type annotations should be specified
    • @file the framework should compare the reference data with files
    • @raster the framework should compare the reference data with raster maps using r.out.ascii for export
    • @vector the framework should compare the reference data with vector maps using v.out.ascii for export
    • @raster3d the framework should compare the reference data with raster3d maps using r3.out.ascii for export
    • @color the framework should compare the reference data with color rules using r.color.out for export
    • @table the framework should compare the reference data with SQL tables using db.select for export
    • ... please add more

Reference data for validation must be located in the module/library directory. The reference data names must be identical with the generated data (files, maps, ...) except that reference data always has a .ref suffix.

Tests are in each module's and in each library's folder. To test library functions special modules must be implemented. Library test modules test the library functions directly and should be written in C. Have a look at the test directories in the g3d, gpde and gmath libraries of grass7.

Framework should be able to generate and compare grass data types: raster, vector, raster3d, general, db, icon, imagery, d.*?

wxGUI testing should be tested separately.

Automated tests on server generates HTML report. Test several platforms.

Here some examples already available in grass7:

test.r3.out.vtk.sh

# This script tests the export of voxel data
# into the VTK format. Almost all options of
# r3.out.vtk are tested. Validation data for each test
# is located in the module source directory

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now generate two elevation maps, we have 8 rows and use
# them for elevation computation. The rows are counted from north
# to south. So in the south the elevation must have a maximum.
r.mapcalc --o expr="elev_bottom = row()"
r.mapcalc --o expr="elev_top = row() + 50"
# Now create a voxel map with value = col + row + depth. Beware the
# raaster3d module count from south to north.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 2 || row() == 7, null(), volume)"
# Create the rgb maps
r3.mapcalc --o expr="volume_rgb = volume_null * 5"

# The first @test just exports the volume map as cell and point data
# using a low precision and replaces the default null value with 0
# the created @files should be compared with the reference data
r3.out.vtk --o input=volume_null output=test_volume_null_1_cells.vtk dp=3 null=0
r3.out.vtk -p --o input=volume_null output=test_volume_null_1_points.vtk dp=3 null=0

# The second @test adds rgb and vector maps. We re-use the created volume map
# for vector creation. The rgb value must range fom 0 - 255. The generated @files
# should be compared with the reference data.
r3.out.vtk --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_cells_rgb_vect.vtk dp=3 null=-1.0
r3.out.vtk -p --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_points_rgb_vect.vtk dp=3 null=-1.0

# The third @test uses raster maps to create volume data with an elevation surface
# The maximum elevation should be in the south. Reference @files are present for validation.
r3.out.vtk -s --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_cells_elevation.vtk dp=3 null=0
r3.out.vtk -sp --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_points_elevation.vtk dp=3 null=0

The following reference files are located in the r3.out.vtk directory:

-rw-r--r-- 1 soeren users 104556 16. Jun 18:14 test_volume_null_1_cells_elevation.ref
-rw-r--r-- 1 soeren users   3434 16. Jun 18:14 test_volume_null_1_cells.ref
-rw-r--r-- 1 soeren users  22749 16. Jun 18:14 test_volume_null_1_cells_rgb_vect.ref
-rw-r--r-- 1 soeren users  13360 16. Jun 18:14 test_volume_null_1_points_elevation.ref
-rw-r--r-- 1 soeren users   3435 16. Jun 18:14 test_volume_null_1_points.ref
-rw-r--r-- 1 soeren users  22750 16. Jun 18:14 test_volume_null_1_points_rgb_vect.ref

test.r3.cross.rast.sh

# This script tests the r3.cross.rast module to compute
# cross section raster maps based on a raster3d and elevation map

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=100 b=0 t=50 res=10 res3=10 -p3
# We create several elevation maps to create slices of the voxel map
# We start from bottom and raise to the top. Value equal or greater 50 
# should generate grass NULL values
r.mapcalc --o expr="elev_0 = 0"
r.mapcalc --o expr="elev_1 = 5"
r.mapcalc --o expr="elev_2 = 15"
r.mapcalc --o expr="elev_3 = 25"
r.mapcalc --o expr="elev_4 = 35"
r.mapcalc --o expr="elev_5 = 45"
r.mapcalc --o expr="elev_NAN = 50"
r.mapcalc --o expr="elev_cross = float(col()* 5)"
# Now create a voxel map with value = col + row + depth. Beware the
# raster3d module count from south to north.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 1 || row() == 5, null(), volume)"

# We @test the creation of slices and a cross section of the voxel map. Reference data
# for @raster map validation is located in the r3.cross.rast source directory.
# Slice 0 and 1 should be identical. The last slice should consist only of grass NULL values
r3.cross.rast --o input=volume_null elevation=elev_0 output=test_cross_section_slice_0
r3.cross.rast --o input=volume_null elevation=elev_1 output=test_cross_section_slice_1
r3.cross.rast --o input=volume_null elevation=elev_2 output=test_cross_section_slice_2
r3.cross.rast --o input=volume_null elevation=elev_3 output=test_cross_section_slice_3
r3.cross.rast --o input=volume_null elevation=elev_4 output=test_cross_section_slice_4
r3.cross.rast --o input=volume_null elevation=elev_5 output=test_cross_section_slice_5
r3.cross.rast --o input=volume_null elevation=elev_NAN output=test_cross_section_slice_NAN
r3.cross.rast --o input=volume_null elevation=elev_cross output=test_cross_section_result

The following reference files are located in the r3.cross.rast directory:

-rw-r--r-- 1 soeren users   264 16. Jun 18:14 test_cross_section_result.ref
-rw-r--r-- 1 soeren users   264 16. Jun 18:14 test_cross_section_slice_0.ref
-rw-r--r-- 1 soeren users   264 16. Jun 18:14 test_cross_section_slice_1.ref
-rw-r--r-- 1 soeren users   269 16. Jun 18:14 test_cross_section_slice_2.ref
-rw-r--r-- 1 soeren users   273 16. Jun 18:14 test_cross_section_slice_3.ref
-rw-r--r-- 1 soeren users   276 16. Jun 18:14 test_cross_section_slice_4.ref
-rw-r--r-- 1 soeren users   279 16. Jun 18:14 test_cross_section_slice_5.ref
-rw-r--r-- 1 soeren users   222 16. Jun 18:14 test_cross_section_slice_NAN.ref

Test framework:

What the test framework should do:

• Creation of a test mapset for each test case in a specific test location located in the grass sources
• Setting the environment variables to the test location and grass installation (grass environment to run modules)
• Parsing and interpretation and execution of test scripts
• Support of several test scripts in a single module directory
• Run of location specific test scripts (only LL or UTM test scripts)
• Handles module test results codes and stderr messages
• Validation of module output based on reference data and data type annotations in the test description
• Creates a HTML report for single modules and the whole test run
• Deletion of the generated test mapset to clean up the test location

Timeline and status

TBD

Interested people

• Sören Gebbert
• Anne Ghisla
• Martin Landa
• Add your name here