Testing

gdalautotest

The primary means of testing is to run the gdalautotest python regression test suite. After building with either the old or new generation python bindings, and installing them (or adding them to your path from the build tree) do the following:

% svn checkout https://svn.osgeo.org/gdal/trunk/autotest
% cd autotest
% ./run_all.py 

This should result in something ending like:

 ------------ Failures ------------
Script: ogr/ogr_dods.py
  TEST: ogr_dods_1 ... fail
Script: gdrivers/gdalhttp.py
  TEST: http_1 ... fail
    Failed to open dataset: http://home.gdal.org/~warmerda/frank.gif
 ----------------------------------

Test Script: osr/osr_url.py
Succeeded: 756
Failed:    2 (0 blew exceptions)
Skipped:   49

Skipped tests are ok (normally because particular drivers are not compiled in), but failed tests should be investigated. Some details of the failed test should be shown just before the final summary. It is then possible to cd down into the directory of that test, and run it in isolation (perhaps with --debug on) to try and isolate what is going wrong.

The Buildbot runs will run the gdalautotest suite as well.

Locale Testing

To test if GDAL/OGR is working well in a particular locale it is possible to pass the desired locale to most GDAL commands, including the gdalautotest scripts via the --locale switch. On my Ubuntu system I have specifically installed the de (German) locales which uses a comma in place of a period for a decimal marker. To check if things are working in this condition I do something like:

% cd autotest/gdrivers
% ./wcs.py --locale de_DE.utf8

Exact locale names may vary by platform and installation details. On linux it is usually possible to get a list of available locales using the "locale -a" command.