Do we have an equivalent of south's --update? This would mean you don't get many files. We don't want to make it too hard for people to work in a strict TDD fashion.
M On 25 Mar 2014 18:15, "Andrew Godwin" <[email protected]> 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]>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]. >> 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/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/CAFwN1ur1EAxBoDC4O_-LD6B_CsGv3iE7jxCZRts-7ORfKKc%2Buw%40mail.gmail.com<https://groups.google.com/d/msgid/django-developers/CAFwN1ur1EAxBoDC4O_-LD6B_CsGv3iE7jxCZRts-7ORfKKc%2Buw%40mail.gmail.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/CAMwjO1HuaBKsZ1ce3uUXFwjSjwVrh1NLW%2Bh1HLEgroX4azFbKg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
