This TestSettingsManager class takes some of the pain out of making temporary changes to settings for the purposes of a unittest or doctest. It will keep track of the original settings and let you easily revert them back when you're done.
It also handles re-syncing the DB if you modify INSTALLED_APPS, which is especially handy if you have some test-only models in tests/models.py. This makes it easy to dynamically get those models synced to the DB before running your tests.
Sample doctest usage, for testing an app called "app_under_test," that has a tests/ sub-module containing a urls.py for testing URLs, a models.py with some testing models, and a templates/ directory with test templates:
>>> from test_utils import TestManager; mgr = TestManager()
>>> import os
>>> mgr.set(INSTALLED_APPS=('django.contrib.contenttypes',
... 'django.contrib.sessions',
... 'django.contrib.auth',
... 'app_under_test',
... 'app_under_test.tests'),
... ROOT_URLCONF='app_under_test.tests.urls',
... TEMPLATE_DIRS=(os.path.join(os.path.dirname(__file__),
... 'templates'),))
...do your doctests...
>>> mgr.revert()
**SSL Middleware**
This middleware answers the problem of redirecting to (and from) a SSL secured path
by stating what paths should be secured in urls.py file. To secure a path, add the
additional view_kwarg 'SSL':True to the view_kwargs.
For example
`
urlpatterns = patterns('some_site.some_app.views',
(r'^test/secure/$','test_secure',{'SSL':True}),
)
`
All paths where 'SSL':False or where the kwarg of 'SSL' is not specified are routed
to an unsecure path.
For example
`
urlpatterns = patterns('some_site.some_app.views',
(r'^test/unsecure1/$','test_unsecure',{'SSL':False}),
(r'^test/unsecure2/$','test_unsecure'),
)
`
**Gotcha's**
Redirects should only occur during GETs; this is due to the fact that
POST data will get lost in the redirect.
**Benefits/Reasoning**
A major benefit of this approach is that it allows you to secure django.contrib views
and generic views without having to modify the base code or wrapping the view.
This method is also better than the two alternative approaches of adding to the
settings file or using a decorator.
It is better than the tactic of creating a list of paths to secure in the settings
file, because you DRY. You are also not forced to consider all paths in a single
location. Instead you can address the security of a path in the urls file that it
is resolved in.
It is better than the tactic of using a @secure or @unsecure decorator, because
it prevents decorator build up on your view methods. Having a bunch of decorators
makes views cumbersome to read and looks pretty redundant. Also because the all
views pass through the middleware you can specify the only secure paths and the
remaining paths can be assumed to be unsecure and handled by the middleware.
This package is inspired by Antonio Cavedoni's SSL Middleware
Notes:
Updated per Jay Parlar at http://www.djangosnippets.org/snippets/240/ - Added a test for the way webfaction handles forwarded SSL requests.
I'm posting this here mostly because I need a more permanent home for this than my lappy's hard drive. I hope it's interesting to other people, though.
Anyway - this script is what I use to test Django against multiple versions of Python and multiple databases. To actually run this you'll of course need Python 2.3, 2.4, and 2.5 installed along with MySQL, PostgreSQL, and sqlite3 -- and the associated database wrappers for all 3 Pythons.
Yes, for the record, I've got all those things installed on my laptop.
If you can somehow make that work, though, running this script will print out a nice little summary of what's failing against which versions of Python and which database. Run with `-v` to see the actual failures.