Running gis tests via runtests doesn't work.

[Malcolm Tredinnick]

In r9918, we added the facility to use TEST_RUNNER for Django's standard runtests.py path. I naïvely tried to use that today and the wheels fell off in an interesting fashion.

The settings file was:

DATABASE_ENGINE = 'postgresql_psycopg2'
DATABASE_NAME = 'django'
TEST_RUNNER = 'django.contrib.gis.tests.run_gis_tests'
POSTGIS_TEMPLATE = 'template_postgis'

and then I invoked

./runtests.py --settings=settings7 gis

and was handed

Traceback (most recent call last):
  File "./runtests.py", line 187, in <module>
    django_tests(int(options.verbosity), options.interactive, args)
  File "./runtests.py", line 157, in django_tests
    failures = test_runner(test_labels, verbosity=verbosity, interactive=interactive, extra_tests=extra_tests)
  File "/usr/lib/python2.5/site-packages/django/contrib/gis/tests/__init__.py", line 88, in run_gis_tests
    gis_suite, test_models = geo_suite()
  File "/usr/lib/python2.5/site-packages/django/contrib/gis/tests/__init__.py", line 50, in geo_suite
    tsuite = getattr(__import__('django.contrib.gis.tests', globals(), locals(), [test_suite]),test_suite)
  File "/usr/lib/python2.5/site-packages/django/contrib/gis/tests/test_spatialrefsys.py", line 4, in <module>
    from django.contrib.gis.models import SpatialRefSys
ImportError: cannot import name SpatialRefSys

Something's going wonky in the import stuff in get_suite(), but I can't figure it out yet. Would be nice if this more or less just worked at some point, though.

This isn't a regression, by the way, since, previously, no tests would be run at all, as runtests.py wouldn't use the gis test runner. So it's an enhancement to make this work. Also, it might well be made easier once we land #8193.

[Malcolm Tredinnick]

I poked at this a bit more. The problem is all the places django.contrib.gis imports django.contrib.gis.db.backend, which requires actually executing database operations immediately (such as querying the library version). Many of those imports aren't in the test code, so delaying them affects mainline code (django.contrib.gis.db.models.aggregates, for example)

It looks to be fairly fiddly to easily change that, although it's probably something to look at in the future (post-1.1). Everywhere else in Django we've aimed for being able to import things and then call settings.configure() and the current gis behaviour doesn't allow that, for example.

For right now, though, it's probably not worth investing a lot of time pre-1.1 to fix this. It looks a little too invasive. I'll leave the milestone alone for now in case I've missed something obvious that Justin notices, but I could live with punting this until after the release. It's still possible to test things via another app and it's a nice-to-have, not a necessity.

[Malcolm Tredinnick]

Punting to later, since apparently Justin has plans to hammer on the gis db interaction later. We can address that then instead of wasting time hacking away now.

[jbronn]

I'll see what I can do.

[jbronn]

(In [14776]) GeoDjango test suite housekeeping. Moved data into fixtures for relatedapp and distapp tests, and made both use Django's TestCase; moved functionality out of GeoDjangoTestSuiteRunner to allow future re-use in runtests.py (refs #10420); compressed test app fixtures and cleaned up imports.

[jbronn]

(In [14812]) [1.2.X] GeoDjango test suite housekeeping. Moved data into fixtures for relatedapp and distapp tests, and made both use Django's TestCase; moved functionality out of GeoDjangoTestSuiteRunner to allow future re-use in runtests.py (refs #10420); compressed test app fixtures and cleaned up imports.

Backport of r14776 from trunk.

[jbronn]

(In [15013]) Fixed #10420 -- GeoDjango tests are run as part of Django tests when using spatial database backends with runtests.py.

[jbronn]

(In [15014]) [1.2.X] Fixed #10420 -- GeoDjango tests are run as part of Django tests when using spatial database backends with runtests.py.

Backport of r15013 from trunk.