Django 1.6 has been finally released… these are the changes I introduced into my codebase

Django 1.6 has been finally released, but this update is quite obtrusive, in fact…

Issue n.1: tests not found!

the dev team has changed significantly how unit tests are discovered and my old approach stopped working (no tests to run found).
In my previous system I created a “tests” package for each app in my project, in these packages I created a test class for each tested class, named like “TestClassName” and I exposed these classes at “tests” package level by customizing its file.
But starting with Django 1.6 the default test runner doesn’t care about “tests” modules/packages, it looks instead for file matching the pattern “test*.py” and since this pattern is CASE SENSITIVE (aaaarghh!!!) my test CLASSES (so they start with an uppercase letter) are ignored! Fortunately is very simple to override the default runner in order to match another pattern :)
This is my custom runner:

from django.test.runner import DiscoverRunner

class TestRunner(DiscoverRunner):

    def __init__(self, pattern=None, top_level=None, verbosity=1, interactive=True, failfast=False, **kwargs):
        super(TestRunner, self).__init__('Test*.py', top_level, verbosity, interactive, failfast, **kwargs)

and in the settings module:

TEST_RUNNER = 'myapp.TestRunner.TestRunner'

Issue n.2: PyCharm Django Tests configuration is now broken!

If you are using PyCharm as your python IDE, the “Django tests” run configuration is now broken (honestly I don’t understand why the guys of JetBrains have set up a such perverse way to run Django tests by writing their own python modules LOL)… so I defined a simple python run configuration in which I call “python test“… it’s not so pleasant, like the Django tests run configuration because is basically the same output of the shell script without the “green bar” and the red/yellow/green buttons that show the results of the run tests… but at the moment it does the job, and the important thing is that, differently from launching tests from the shell I can use breakpoints in the IDE to stop code execution and debug the situation! (like before)
Uh… the good part is that now my tests are executed ~40% faster!!! (10 seconds vs 14 seconds in the old run configuration)

Issue n.3: Where is gone GeoIP?!

Another problem I faced is that the GeoIP wrapper around MaxMind api has been moved from django.contrib.gis.utils to django.contrib.gis.geoip (and this change seems not documented in the release notes!)

Check Django messages (quantity and type) in unit tests

Ok, in this short (but I hope very helpful post), I’m gonna show how to check messages (Django messages framework) in your tests.
I don’t know if there is a better or “normalized” way to do this, but it’s the simplest and effective way I found by myself… so, let’s suppose we have a test in which we want to check that if the submitted form data is invalid, an error message is sent back with the response context:

def testIfSubmittedDataIsInvalidAnErrorMessageIsReturned(self):
    response =, {})
    messages = list(response.context['messages'])
    self.assertEqual(len(messages), 1)
    self.assertEqual(messages[0].level, MSG.ERROR)

MSG is a reference to messages levels constants imported in this way:

from django.contrib.messages import constants as MSG