This is an old issue that (as far as I can see) was never resolved.
My proposed solution would be a flag to the test command to automatically
`makemigrations && migrate`. When this behaviour is enabled, it would also
roll back any generated migrations at the end of the test run. The flag
might not be necessary (could be default behaviour of `test`)
This way you get the benefits of all worlds:
1) uncommitted migration files will be clearly visible after the test run
(for those inclined to forget to makemigrations).
2) The extraneous non-migration creation code can be removed from Django
(probably already has been at this point).
3) Tests are always run against the current state of models
4) Tests are always run at current state of migrations (because it
generates the migrations).
As an extra benefit, it makes testing between branches *so much* easier
because you don't have to worry about rolling back migrations on the
test_db (a PITA as far as I can see).
Regarding the last, is there a flag to make migrate target the test_db(s)?
Best,
Casey
On Tuesday, 25 March 2014 14:21:51 UTC-3, Bernie Sumption 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 (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/2aee60d5-e96b-4c96-8f87-150d9de46215%40googlegroups.com.
