Andrew, Can you clarify exactly what is deprecated in this work-around? I don't see anything in the deprecation timeline to remove MIGRATION_MODULES nor any pending deprecations related to its usage. It seems like could probably be replaced by something that uses the app-loading/app-configs instead but it does look like it's been done.
Best, Mark On Tuesday, March 25, 2014 2:14:55 PM UTC-4, Andrew Godwin wrote: > > Yes, the new behaviour is by design, in the sense that the workaround you > mentioned will be deprecated in 1.9 (along with all syncdb-related > functionality). This way, tests always run against the version of your > models that production would run, so you don't run the risk of the tests > passing locally as they're not using migrations, pushing it live, and then > things failing in production as the tables don't match. > > I'm happy to take a small patch to the docs to mention that you need to > run makemigrations for tests to see your database changes, but the > workaround shouldn't be in there - as I said, it's already part of the > deprecation cycle. > > Andrew > > > On Tue, Mar 25, 2014 at 10:21 AM, Bernie Sumption > <[email protected]<javascript:> > > wrote: > >> Hi Django devs, >> >> I've just started a new project in 1.7b, and the development experience >> working with unit tests on models is more complicated than it was in 1.6. >> It's all down to how the throwaway test databases are created. In 1.6, the >> create_test_db function "Creates a new test database and runs syncdb >> against it." In 1.7, it runs "migrate". >> >> While generally speaking, migrate is the new syncdb, this behaviour is >> not ideal for tests. In 1.6 "syncdb" created a database reflecting the >> current state of the models in models.py. "migrate" creates a database >> reflecting the state of the models at the last time makemigrations was run. >> If you're doing TDD and constantly making small changes to your models then >> runnning unit tests, you have to run makemigrations before each test run to >> get your tests to work. You therefore end up with many tiny migration files >> representing the minute-by-minute history of development. >> >> I came up with a pretty effective workaround that is working for me, but >> I thought I'd post this here as others are sure to encounter this issue, >> and I think that it makes more sense for the behaviour produced by this >> workaround to be the default for running tests. >> >> If makemigrations has not yet been run, the "migrate" command treats an >> app as unmigrated, and creates tables directly from the models just like >> syncdb did in 1.6. I defined a new settings module just for unit tests >> called "settings_test.py", which imports * from the main settings module >> and adds this line: >> >> MIGRATION_MODULES = {"myapp": "myapp.migrations_not_used_in_tests"} >> >> Then I run tests like this: >> >> DJANGO_SETTINGS_MODULE="myapp.settings_test" python manage.py test >> >> This fools migrate into thinking that the app is unmigrated, and so every >> time a test database is created it reflects the current structure of >> models.py. >> >> So my feature request is as follows: >> >> If the new behaviour is by design and considered desirable, then it is a >> big change from the previous version and should be prominently documented >> in the migrations and testing pages, along with the workaround. I'm happy >> to write this documentation if that's the way you want to go. >> >> However, if the new behaviour is not by design but just a by-product of >> the new migrations feature, I suggest making the workaround the default >> behaviour. I don't (yet!) know enough about Django internals to volunteer >> for this however. >> >> Thanks for your time, >> >> Bernie :o) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to >> [email protected]<javascript:> >> . >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/00e9a053-3e61-4c5d-8fcc-5a4d67deab38%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/00e9a053-3e61-4c5d-8fcc-5a4d67deab38%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5674c27e-2ed9-4d25-bd44-238ff29014ea%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
