The testing framework has leaky scoping when defining models in tests

[Nicholas A Lourie]

If you define two subclasses of the models.Model class with the same name in two different methods of a TestCase subclass, they should exist in separate scopes and so be two completely distinct classes; however, whichever test method is run first has it's model subclass definition eclipse the others by the same name.

This bug occurs in Django 1.6, but in Django 1.7 this bug is avoided because defining the model in two different scopes raises a RuntimeError with a message along the lines of "RuntimeError: Conflicting 'class' models in application 'test_bug'".

See attached example.

[Nicholas A Lourie]

a minimal example of the bug in question.

[Nicholas A Lourie]

Added as easy pickings because I'm guessing that you could just raise the same runtime error that is raised in Django 1.7, though I'm unfamiliar with how that error is raised.

[Aymeric Augustin]

Indeed the bug was fixed in Django 1.7 by the app-loading refactor -- which I didn't find particularly easy.

That refactor cannot be backported to Django 1.6 because it introduces several backwards incompatibilities.

The specific problem you mention cannot be fixed in Django 1.6 because some apps (eg. django-oscar) rely on the second definition of a model being silently ignored.

[Carl Meyer]

Just to clarify for anyone who finds this in future: the issue has nothing to do with scoping in the testing framework specifically, it's about how Django model registration works. (That is, model classes are automatically globally registered, keyed by app-label and class name).