Testing GeoDjango Apps

Creating a spatial database may require extra steps. To accommodate this, GeoDjango includes a test runner that will scaffold a spatial database automatically. To have your tests utilize the runner, just configure your TEST_RUNNER in your settings like the following:

TEST_RUNNER='django.contrib.gis.tests.run_tests'

If you want to run GeoDjango’s test suite (do not use for testing your applications) then the runner would be configured like so:

TEST_RUNNER='django.contrib.gis.tests.run_gis_tests'

Note

In order to create a spatial database with PostGIS or Oracle, the DATABASE_USER setting (or TEST_DATABASE_USER, if optionally defined on Oracle) will require database superuser privileges.

Besides configuring the TEST_RUNNER setting, there are other options to consider depending on your spatial backend (no additional options or configuration instructions for the Oracle or MySQL spatial backends).

PostGIS

Settings

POSTGIS_SQL_PATH

If not using the POSTGIS_TEMPLATE setting, the GeoDjango test runner assumes that the PostGIS SQL files (lwpostgis.sql and spatial_ref_sys.sql) are installed in the directory specified by the following command:

$ pg_config --sharedir

If that command cannot be executed, the test runner will default to /usr/local/share, unless this setting is configured with a different location. For example, some PostGIS packages for Ubuntu put the files in a nonstandard location, and placing this in the settings would allow GeoDjango to find the files:

POSTGIS_SQL_PATH='/usr/share/postgresql-8.3-postgis'

POSTGIS_TEMPLATE

New in version 1.1.

If you have a PostGIS template already, then just configure with the name of the template in your settings, for example:

POSTGIS_TEMPLATE='template_postgis'

POSTGIS_VERSION

New in version 1.1.

When GeoDjango’s spatial backend initializes on PostGIS, it has to perform a SQL query to determine the version. Setting the version manually prevents this query to the database:

POSTGIS_VERSION=('1.3.6', 1, 3, 6)

Obtaining Sufficient Privileges

Depending on your configuration, this section describes several methods to configure a database user with sufficient privileges to run tests for GeoDjango applications on PostgreSQL.

Make User a Superuser

This may be done at the time the user is created, for example:

$ createuser --superuser <user_name>

Or you may alter the user’s role from the SQL shell (assuming this is done from an existing superuser role):

postgres# ALTER ROLE <user_name> SUPERUSER;

Create Local PostgreSQL Database

1. Initialize database: initdb -D /path/to/user/db
2. If there’s already a Postgres instance on the machine, it will need to use a different TCP port than 5432. Edit postgresql.conf (in /path/to/user/db) to change the database port (e.g. port = 5433).
3. Start this database pg_ctl -D /path/to/user/db start

Windows

On Windows platforms the pgAdmin III utility may also be used as a simple way to add superuser privileges to your database user.

By default, the PostGIS installer on Windows includes a template spatial database. Take advantage of it by adding this to your settings:

POSTGIS_TEMPLATE='template_postgis'

SpatiaLite

New in version 1.1.

You will need to download the initialization SQL script for SpatiaLite:

$ wget http://www.gaia-gis.it/spatialite/init_spatialite-2.3.zip
$ unzip init_spatialite-2.3.zip

If init_spatialite-2.3.sql is in the same path as your project’s manage.py script and your TEST_RUNNER is set, then all you have to do is:

$ ./manage.py test

Settings

SPATIALITE_SQL

New in version 1.1.

By default, the GeoDjango test runner looks for the SpatiaLite SQL in the same directory where it was invoked (by default the same directory where manage.py is located). If you want to use a different location, then you may add the following to your settings:

SPATIALITE_SQL='/path/to/init_spatialite-2.3.sql'