On Mon, Jan 18, 2016 at 04:25:59AM -0800, Brutus Schraiber wrote: > Am Samstag, 16. Januar 2016 22:23:06 UTC+1 schrieb Vijay Khemlani: > > > > At least to me it doesn't make a lot of sense to define new models in your > > tests, but I also don't know the particular problem you are solving. > > > > I have an app, that defines a couple of *abstract models* and *mixins* in > it's `models.py`, that are only used in other apps. > > To test those abstract models and mixins I created concrete models (from > `django.db.models.Model`), that use these abstract models and mixins, in > `test.py`. > > I created them in `test.py`, so that the test models don't get created in > the DB outside of test running. I thought this the way to handle such > things in Django? > > At least for me this generally works fine. In a special case I get an > `django.db.utils.ProgrammingError` from one of my test models though. To > debug this, I wanted to take a look at the SQL Django generated for it.
Hi Brutus, Could you perhaps post the full traceback of the ProgrammingError? It smells a bit like your test models don't get imported early enough to be fully initialized before database creation happens. And this might be caused precisely by the fact that your models are not inside models.py. As for your original question, unless you put all your models into models.py of an app inside INSTALLED_APPS, or at least import them from within such a models.py module, they won't be considered at all when generating migrations, or when dumping out the creation SQL. When you run a management command, ``django.setup()`` is called, which populates the model registry by importing the models module of each installed app, not much else. Particularly not app.tests. So there's no way for the ``sql`` management command to be aware of your test models. The tests module is only imported when running tests by the test runner (unless you import it from somewhere else in your app, but that's not a very usual thing to do). That happens after ``django.setup()`` has finished, at which point models should already be properly initialized, which, obviously, is not the case with models in tests.py. In theory, it should work – the test runner tries to import all test modlues before setting up the test database, so in case everything is correct, all deferred model setup actions should still finish before creating the database. However, if there is some kind of error, they might not, and that means it will be harder to debug those situations. Really, do yourself a favor, create a separate app for your tests, with its own models, and its own settings. That is the most painless way to have additional testing models. You can take inspiration from the following section of the docs: https://docs.djangoproject.com/en/1.9/topics/testing/advanced/#using-the-django-test-runner-to-test-reusable-applications Regards, Michal -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/20160118192319.GZ20308%40koniiiik.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
