Login

TestSettingsManager: temporarily change settings for tests

Author:
carljm
Posted:
August 30, 2008
Language:
Python
Version:
.96
Score:
7 (after 7 ratings)

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()
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
from django.conf import settings
from django.core.management import call_command
from django.db.models import loading
from django.test import TestCase

NO_SETTING = ('!', None)

class TestSettingsManager(object):
    """
    A class which can modify some Django settings temporarily for a
    test and then revert them to their original values later.

    Automatically handles resyncing the DB if INSTALLED_APPS is
    modified.

    """
    def __init__(self):
        self._original_settings = {}

    def set(self, **kwargs):
        for k,v in kwargs.iteritems():
            self._original_settings.setdefault(k, getattr(settings, k,
                                                          NO_SETTING))
            setattr(settings, k, v)
        if 'INSTALLED_APPS' in kwargs:
            self.syncdb()

    def syncdb(self):
        loading.cache.loaded = False
        call_command('syncdb', verbosity=0)

    def revert(self):
        for k,v in self._original_settings.iteritems():
            if v == NO_SETTING:
                delattr(settings, k)
            else:
                setattr(settings, k, v)
        if 'INSTALLED_APPS' in self._original_settings:
            self.syncdb()
        self._original_settings = {}


class SettingsTestCase(TestCase):
    """
    A subclass of the Django TestCase with a settings_manager
    attribute which is an instance of TestSettingsManager.

    Comes with a tearDown() method that calls
    self.settings_manager.revert().

    """
    def __init__(self, *args, **kwargs):
        super(SettingsTestCase, self).__init__(*args, **kwargs)
        self.settings_manager = TestSettingsManager()
    
    def tearDown(self):
        self.settings_manager.revert()

More like this

  1. Template tag - list punctuation for a list of items by shapiromatron 11 months, 2 weeks ago
  2. JSONRequestMiddleware adds a .json() method to your HttpRequests by cdcarter 11 months, 3 weeks ago
  3. Serializer factory with Django Rest Framework by julio 1 year, 6 months ago
  4. Image compression before saving the new model / work with JPG, PNG by Schleidens 1 year, 7 months ago
  5. Help text hyperlinks by sa2812 1 year, 7 months ago

Comments

carljm (on August 30, 2008):

I kept having the feeling as I was writing this code that there MUST be some already-existing way to do this that I'm just too blind to see. Is there a better pattern for this that I'm missing?

#

reanes (on September 23, 2008):

What I do is define a new test_settings.py file that looks like:

from settings import *
# add any additional or overridden settings and here
# you could add your automated syncdb stuff in here as well...

Then copy your manage.py to manage_test.py and change the line: "import settings" to "import test_settings as settings"

run manage_test.py instead of manage.py whenever you want to use your test settings.

#

bob84123 (on December 18, 2008):

reanes's suggestion is great. Just remember to use

from django.conf import settings

rather than 'import settings' in your code that reads the settings, otherwise it'll just read the normal settings.py anyway.

#

carljm (on February 3, 2009):

Hmm, that solution doesn't seem like it would cover my use cases. I often have particular apps that need particular test settings (or additional test models), and it doesn't make sense to include those in the test settings for every single app.

#

muhuk (on October 7, 2009):

@carljim: it complains that ImproperlyConfigured: App with label testapp could not be found when I modify INSTALLED_APPS (Django 1.1). syncdb below seems to work:

def syncdb(self):
    loading.cache.loaded = False
    loading.cache.app_store = SortedDict()
    loading.cache.app_models = SortedDict()
    loading.cache.app_errors = {}
    loading.cache.handled = {}
    loading.cache.postponed = []
    call_command('syncdb', verbosity=0)

#

muhuk (on October 7, 2009):

@carljim: I guess I was wrong, syncdb method was working just fine. But I had to subclass TransactionTestCase in order to get tables for new models created.

#

rix (on December 8, 2009):

Really nice, very useful snippet! Thanks!

#

carljm (on October 5, 2010):

Note that the syncdb portion of this will only work in Django 1.1+ if you subclass from TransactionTestCase, which will slow your tests significantly. I don't really recommend the use of this snippet anymore.

#

tobia (on November 5, 2012):

Nice, thanks.

A note about NO_SETTING: setting it to something unlikely and then using == for comparison is less than ideal, because the unlikely value ('!', None) could be used in some remote setting.

A better approach is to create a new object for it, for example NO_SETTING = object(), and then using ≪is≫ for comparison. This is cleaner and safer, because Python will make sure no other value will ever evaluate true for ≪x is NO_SETTING≫.

#

Please login first before commenting.