At the risk of reviving an old topic, I wanted to add one significant point
in favor of (and mitigation for) running tests with migrations disabled:
Speed.
Creating a test DB in sqlite for our project (~100 database tables) takes
approximately 1-2 minutes on most developer machines. 1-2 minutes of idle
time to run any test was just unacceptable so we disabled migrations by
setting fake migrations in MIGRATION_MODULES and brought the test DB
creation time down to about 5 seconds (!!).
However the risk of committing invalid code because someone forgot to
makemigrations is real. We've addressed it by only overriding migrations on
our local test settings and still having migrations run on our CI server.
We have our CI server use settings.test, while developers running tests on
their local machine use settings.test_local which is just:
from settings.test import *
MIGRATION_MODULES = ((app, '%s.fake_migrations' % app) for app in
INSTALLED_APPS)
This seems to get us the best of both worlds. I was surprised to read
through this thread and not see other mentions of the performance
implications of running migrations on every test run. I'd be curious to
hear if this has been a bottleneck for other teams.
-Chris
On Tuesday, March 25, 2014 10:21:51 AM UTC-7, 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 [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/371a1e36-b752-4dad-8bc8-08c8b643e9c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
