1

I'm using Django 1.4 with Python 2.7 on Ubuntu 12.10.

I have a project with several apps and dozens of unit tests. We've recently run into a little issue using the @override_settings decorator.

Here is some code:

@override_settings(MEDIA_URL='/test/media/')
    def test_get_content_dict(self):
        self.assertEqual(
                self.offer.get_content_dict(),
                { 'some stuff': some stuff }

When tests are run at the app level everything passes.

python manage.py test my_app --settings=proton.settings.test

But when we run at the project level it fails.

python manage.py test --settings=proton.settings.test

It's failing due to some stuff using /test/media but the model method offer.get_contect_dict() using /media, which is our actual MEDIA_URL.

We can change the MEDIA_URL in our settings/test.py file, but that would require all tests to use /test/media (which might be a good idea anyway).

Clearly the problem is in Django's core.files.storage.FileSystemStorage.__init__() - it sets the base_url earlier in the test suite but does not re-instantiate the object after each test (for obvious reasons) so the @override_settings doesn't actually do anything.

Is this a bug or is this working as intended? Any suggestions to an elegant solution other than forcing all unit tests to use /test/media by setting our MEDIA_URL constant in our settings/test.py to /test/media?

Rico
  • 5,692
  • 8
  • 46
  • 63
  • 1
    I agree that it might be a good idea just to have all test code run against `/test/media`. Otherwise, maybe `get_content_dict` could accept a `base_url` kwarg? – dokkaebi Nov 13 '12 at 19:31
  • @dokkaebi We decided to go with changing the `MEDIA_URL = /test/media` in the `settings/test.py` file and force all tests to use that value. Although it's a simple work-around I don't feel it should have been necessary. After all, what good is `@override_settings` if it can't actually override settings? – Rico Nov 14 '12 at 19:05

0 Answers0