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.
For more options, visit https://groups.google.com/d/optout.
