When I practice TDD I write the test to spec, and then write the model and view code, so I usually have about the same amount of model changes as otherwise (as, having written the tests, I usually have a clearer idea of what fields I need). I agree that if you're incrementally writing tests on top of models, however, it could be extra verbose, but bear in mind that having hundreds of migrations on 1.7 is easily solved by a single `squashmigrations` command - much easier than on South (and performance on large migration sets should also be improved).
I'd be willing to keep the current contract of "things without a migrations directory don't get migrated", but I suspect you're doing things on apps that already have migrations (which makes my reticence to add a setting even bigger - if you "syncdb" an app with migrations to a main database, you have forever ruined the migration tracking on it). Would that work? Or do you want to do this on apps which are already several migrations along? (If that's the case, I suspect we might have to look at re-introducing --update, which is going to be near-impossible to do before release with the new creation system). Andrew On Wed, Mar 26, 2014 at 3:13 AM, Bernie Sumption <[email protected]>wrote: > we can't promote adding random strings to MIGRATION_MODULES as the >> suggested way to "get around" migrations for tests. >> > > I agree, my workaround is a hack. It would be better to introduce a flag > or setting designed specifically for this use case. > > >> In my opinion, the whole point of migrations is that you know you have >> the same schema everywhere, and it's especially important you use them >> during tests. >> > > If you view tests as a verification tool that is used before deployment or > committing to check that the system is working as desired then yes, this is > true. If you're practicing TDD, then tests are something else too - they're > a development environment. They're the primary way of interacting with your > code. Add a field, run tests. Rename it, run tests. Change its options, run > tests. > > The fact is, Django 1.6 and South supported this use case very well, > Django 1.7 does not. > > -- > 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/ac7d9f74-691f-4ec8-8900-434f8e0a93ff%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/ac7d9f74-691f-4ec8-8900-434f8e0a93ff%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/CAFwN1ur8KPPfKP-5tOs7j7nTzQCJr-ehVJqz51OJq-02FG_Grg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
