Since version 1.7, Django creates migrations for more than just changes to
your model fields. It’s easy to forget to create a migration after changing,
verbose_name_plural of a model class - I’ve done this many times.
This can lead to a mess down the line when multiple developers all end up
creating the same migration in separate branches.
You can avoid this situation by checking for missing migrations in your test suite:
Here we call the
makemigrations command in “dry-run” mode and test the
exit code to determine if there are any missing migrations. If there are missing
migrations, the test will fail and print the captured output from the
Note that if you are using a custom
MIGRATION_MODULES setting to avoid
applying migrations during
tests, you need to restore its default value for
the above command to work:
Credit for this implementation belongs to Mozilla’s Ed Morley, who committed a similar fix for their treeherder project. The above snippets are slightly extended versions of his original.
- Here’s another approach by YunoJuno that achieves the same effect.
- Patterns of flakey Python tests
- Integrating Asana and GitHub
- Durable database transactions in Django
- Python interfaces a la Golang
- Beware changing the "related name" of a Django model field
- Our in-house coding conventions
- Recommended Django project structure
- Using a custom Sentry client
- Improving accessibility at Octopus Energy
- Django, ELB health checks and continuous delivery
- Organising styles for a React/Django hybrid
- Hello world, would you like to join us?