django-siteprefs
django-siteprefs copied to clipboard
Incompatible with django.test.override_settings
I have a test case using django.test.override_settings
which is failing when the pref is part of siteprefs.
My workaround is to use mock
def test_setting(self):
import foo.settings
with patch('foo.settings', bar='baz'):
...
Using mock brought in its own problems. I tried your pytest-stub which looked interesting, but didnt get that working for this app settings scenario. Also tried a few other over-complicated approaches without success, so I went with the more traditional
def setUp(self):
self._old_bar = foo.settings.BAR
def tearDown(self):
foo.settings.BAR = self._old_bar
def test_foo(self):
foo.settings.BAR = 'baz'
...
- django.test.override_settings - is meant to override a project scoped settings.
- setUp / tearDown are for unittest, and not a-pytest-way.
- I don't know what exactly what behaviour you want to test, but pytest
monkeypatch.setattr
may be a way. - pytest-stub - is for dynamic stub generation for entire packages.
The specific case was I had a test case which was using django.conf.settings
for a variable that was previously unnecessarily project wide. I had moved it into <app>.settings
when implementing siteprefs. In <app>.settings
, the code was using getattr(django_settings, 'APP_VARNAME', default_val)
so @override_settings
should have worked.
I dont like to rely on pytest in tests, especially not with Django projects. It is a nice test runner, for devs, when it works. Its recent aggressive deprecation of features breaking plugins makes it unsuitable for stable / maintenance projects.
This failed under pytest, and I didnt retest under Django test runner - I should do that, as pytest-django init is often out of whack with how Django startup really happens.
Interestingly/annoyingly @override_settings
still didnt work with https://github.com/idlesign/django-siteprefs/pull/25 when using pytest-django, making me even more suspicious that it may not occur if using Django test runner.