testing.txt 6.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210
  1. ======================
  2. Testing GeoDjango apps
  3. ======================
  4. Included in this documentation are some additional notes and settings
  5. for :ref:`testing-postgis` and :ref:`testing-spatialite` users.
  6. .. _testing-postgis:
  7. PostGIS
  8. =======
  9. Settings
  10. --------
  11. .. note::
  12. The settings below have sensible defaults, and shouldn't require manual setting.
  13. .. setting:: POSTGIS_TEMPLATE
  14. ``POSTGIS_TEMPLATE``
  15. ^^^^^^^^^^^^^^^^^^^^
  16. This setting may be used to customize the name of the PostGIS template
  17. database to use. It automatically defaults to ``'template_postgis'``
  18. (the same name used in the
  19. :ref:`installation documentation <spatialdb_template>`).
  20. .. setting:: POSTGIS_VERSION
  21. ``POSTGIS_VERSION``
  22. ^^^^^^^^^^^^^^^^^^^
  23. When GeoDjango's spatial backend initializes on PostGIS, it has to perform
  24. a SQL query to determine the version in order to figure out what
  25. features are available. Advanced users wishing to prevent this additional
  26. query may set the version manually using a 3-tuple of integers specifying
  27. the major, minor, and subminor version numbers for PostGIS. For example,
  28. to configure for PostGIS 1.5.2 you would use::
  29. POSTGIS_VERSION = (1, 5, 2)
  30. Obtaining sufficient privileges
  31. -------------------------------
  32. Depending on your configuration, this section describes several methods to
  33. configure a database user with sufficient privileges to run tests for
  34. GeoDjango applications on PostgreSQL. If your
  35. :ref:`spatial database template <spatialdb_template>`
  36. was created like in the instructions, then your testing database user
  37. only needs to have the ability to create databases. In other configurations,
  38. you may be required to use a database superuser.
  39. Create database user
  40. ^^^^^^^^^^^^^^^^^^^^
  41. To make a database user with the ability to create databases, use the
  42. following command::
  43. $ createuser --createdb -R -S <user_name>
  44. The ``-R -S`` flags indicate that we do not want the user to have the ability
  45. to create additional users (roles) or to be a superuser, respectively.
  46. Alternatively, you may alter an existing user's role from the SQL shell
  47. (assuming this is done from an existing superuser account)::
  48. postgres# ALTER ROLE <user_name> CREATEDB NOSUPERUSER NOCREATEROLE;
  49. Create database superuser
  50. ^^^^^^^^^^^^^^^^^^^^^^^^^
  51. This may be done at the time the user is created, for example::
  52. $ createuser --superuser <user_name>
  53. Or you may alter the user's role from the SQL shell (assuming this
  54. is done from an existing superuser account)::
  55. postgres# ALTER ROLE <user_name> SUPERUSER;
  56. Create local PostgreSQL database
  57. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  58. 1. Initialize database: ``initdb -D /path/to/user/db``
  59. 2. If there's already a Postgres instance on the machine, it will need
  60. to use a different TCP port than 5432. Edit ``postgresql.conf`` (in
  61. ``/path/to/user/db``) to change the database port (e.g. ``port = 5433``).
  62. 3. Start this database ``pg_ctl -D /path/to/user/db start``
  63. Windows
  64. -------
  65. On Windows platforms the pgAdmin III utility may also be used as
  66. a simple way to add superuser privileges to your database user.
  67. By default, the PostGIS installer on Windows includes a template
  68. spatial database entitled ``template_postgis``.
  69. .. _testing-spatialite:
  70. SpatiaLite
  71. ==========
  72. Make sure the necessary spatial tables are created in your test spatial
  73. database, as described in :ref:`create_spatialite_db`. Then just do this::
  74. $ python manage.py test
  75. Settings
  76. --------
  77. .. setting:: SPATIALITE_SQL
  78. ``SPATIALITE_SQL``
  79. ^^^^^^^^^^^^^^^^^^
  80. Only relevant when using a SpatiaLite version older than 3.0.
  81. By default, the GeoDjango test runner looks for the :ref:`file containing the
  82. SpatiaLite dababase-initialization SQL code <create_spatialite_db>` in the
  83. same directory where it was invoked (by default the same directory where
  84. ``manage.py`` is located). To use a different location, add the following to
  85. your settings::
  86. SPATIALITE_SQL='/path/to/init_spatialite-2.3.sql'
  87. .. _geodjango-tests:
  88. GeoDjango tests
  89. ===============
  90. .. versionchanged:: 1.3
  91. GeoDjango's test suite may be run in one of two ways, either by itself or
  92. with the rest of :ref:`Django's unit tests <running-unit-tests>`.
  93. Run only GeoDjango tests
  94. ------------------------
  95. To run *only* the tests for GeoDjango, the :setting:`TEST_RUNNER`
  96. setting must be changed to use the
  97. :class:`~django.contrib.gis.tests.GeoDjangoTestSuiteRunner`::
  98. TEST_RUNNER = 'django.contrib.gis.tests.GeoDjangoTestSuiteRunner'
  99. Example
  100. ^^^^^^^
  101. First, you'll need a bare-bones settings file, like below, that is
  102. customized with your spatial database name and user::
  103. TEST_RUNNER = 'django.contrib.gis.tests.GeoDjangoTestSuiteRunner'
  104. DATABASES = {
  105. 'default': {
  106. 'ENGINE': 'django.contrib.gis.db.backends.postgis',
  107. 'NAME': 'a_spatial_database',
  108. 'USER': 'db_user'
  109. }
  110. }
  111. Assuming the above is in a file called ``postgis.py`` that is in the
  112. the same directory as ``manage.py`` of your Django project, then
  113. you may run the tests with the following command::
  114. $ python manage.py test --settings=postgis
  115. Run with ``runtests.py``
  116. ------------------------
  117. To have the GeoDjango tests executed when
  118. :ref:`running the Django test suite <running-unit-tests>` with ``runtests.py``
  119. all of the databases in the settings file must be using one of the
  120. :ref:`spatial database backends <spatial-backends>`.
  121. .. warning::
  122. Do not change the :setting:`TEST_RUNNER` setting
  123. when running the GeoDjango tests with ``runtests.py``.
  124. Example
  125. ^^^^^^^
  126. The following is an example bare-bones settings file with spatial backends
  127. that can be used to run the entire Django test suite, including those
  128. in :mod:`django.contrib.gis`::
  129. DATABASES = {
  130. 'default': {
  131. 'ENGINE': 'django.contrib.gis.db.backends.postgis',
  132. 'NAME': 'geodjango',
  133. 'USER': 'geodjango',
  134. },
  135. 'other': {
  136. 'ENGINE': 'django.contrib.gis.db.backends.postgis',
  137. 'NAME': 'other',
  138. 'USER': 'geodjango',
  139. }
  140. }
  141. Assuming the settings above were in a ``postgis.py`` file in the same
  142. directory as ``runtests.py``, then all Django and GeoDjango tests would
  143. be performed when executing the command::
  144. $ ./runtests.py --settings=postgis