= Testing = == gdalautotest == The primary means of testing is to run the [https://github.com/OSGeo/gdal/tree/master/autotest 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: {{{ % git clone https://github.com/OSGeo/gdal.git % cd gdal/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. Some optional tests rely on downloading datasets. This requires the environment variable GDAL_DOWNLOAD_TEST_DATA to be set to YES, otherwise those tests will be skipped. Once downloaded, these datasets are cached in autotest/gdrivers/tmp/cache. The [wiki:Buildbot] runs will run the gdalautotest suite as well. The [wiki:AutotestStatus] page lists all GDAL and OGR drivers and whether there is some test for each one in the autotest. === Testing on Windows using old bindings === After you have downloaded the gdalautotest package, you need to check following things: * You have GDAL build using Microsoft Visual C++ compiler * GDAL DLL is available in one of [http://msdn2.microsoft.com/en-us/library/ms682586.aspx searched location]. Simple solution is to add path to directory with GDAL DLL to the PATH environment: {{{ set PATH=C:\software\gdal;%PATH% }}} * Set PYTHONPATH environment variable, so old-gen bindings can be found: {{{ set PYTHONPATH=C:\software\gdal\pymod }}} * Set GDAL_DATA location: {{{ set GDAL_DATA=C:\software\gdal\data }}} It's a good idea to run tests using full path to Python executable: {{{ C:\software\gdal git clone git clone https://github.com/OSGeo/gdal.git cd gdal\autotest C:\Python24\python.exe run_all.py ... }}} ==== Visual C++ 8.0 Notes ==== If you use Microsoft Visual C++ in version 8.0 (from Microsoft Visual Studio 2005), there are a few additional steps required. Python 2.4 and 2.5 is built using Visual C++ 7.0 and 7.1. The Visual C++ 8.0 generates manifest that describes all runtime dependencies of GDAL on Visual C++ libraries. From MSDN article [http://msdn2.microsoft.com/en-us/library/ms235624(VS.80).aspx Visual C++ Libraries as Shared Side-by-Side Assemblies]: Visual C++ libraries cannot be used by a C/C++ application without a manifest binding the application to these libraries. If a C/C++ application that depends on a Visual C++ library does not use a manifest, then an attempt to load the Visual C++ library as a dependent DLL from the application-local folder will result in an error message indicating that this is an unsupported way of loading a Visual C++ library. Because Python binaries were built using older Visual C++, they do not support manifests. In order to run GDAL Autotest package against GDAL DLL and Python bindings built using Visual C++ 8.0, you need to take following additional steps: * Prepare manifest for Python: * Create file python.exe.manifest * If you've built GDAL in release (non-debug) mode, paste following definition to the manifest file: {{{ }}} * If you've built GDAL in debug mode, paste this: {{{ }}} * Add location of runtime libraries files to PATH environment variable. It's important to set proper path depending on GDAL build configuration: * Release mode: {{{ set PATH=C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT;%PATH% }}} * Debug mode: {{{ set PATH=C:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86\Microsoft.VC80.DebugCRT;%PATH% }}} Note, the paths used above are based on default installation of Visual C++. If you combine these additional steps with steps explained in the [wiki:TestingNotes#TestingonWindowsusingoldbindings previous section], you should be ready to run GDAL Autotest. == 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. == OGR driver testing == When developing a new OGR driver, you can test its consistency on a given data file. {{{ % cd apps % make test_ogrsf % ./test_ogrsf your_data_file }}} A report like this will be generated if everything is OK : {{{ INFO: Open of `../../../sample.gpx' using driver `GPX' successful. INFO: Testing layer waypoints. INFO: Feature count verified. INFO: Feature/layer spatial ref. consistency verified. INFO: Spatial filter inclusion seems to work. INFO: Spatial filter exclusion seems to work. INFO: Testing layer routes. INFO: Feature count verified. INFO: Feature/layer spatial ref. consistency verified. INFO: Spatial filter inclusion seems to work. INFO: Spatial filter exclusion seems to work. INFO: Testing layer tracks. INFO: Feature count verified. INFO: Feature/layer spatial ref. consistency verified. INFO: Spatial filter inclusion seems to work. INFO: Spatial filter exclusion seems to work. }}}