Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Test Django data migrations
Test (data) migrations in Django.
This uses py.test/pytest-django (the `transactional_db` fixture comes from there),
but could be easily adopted for Django's testrunner:
from django.test.testcases import TransactionTestCase
class FooTestcase(TransactionTestCase):
def test_with_django(self):
This example tests that some fields are properly migrated from a `Profile` model
to `User`.
from django.db import connection
from django.db.migrations.executor import MigrationExecutor
def test_migrate_profile_to_user(transactional_db):
executor = MigrationExecutor(connection)
app = "YOUR_APP"
migrate_from = [(app, "000X_before")]
migrate_to = [(app, "000X_after")]
old_apps = executor.loader.project_state(migrate_from).apps
# Create some old data.
Profile = old_apps.get_model(app, "Profile")
old_profile = Profile.objects.create(email="email",
# Migrate forwards.
executor.loader.build_graph() # reload.
new_apps = executor.loader.project_state(migrate_to).apps
# Test the new data.
Profile = new_apps.get_model(app, "Profile")
User = new_apps.get_model(app, "UserEntry")
assert 'firstname' not in Profile._meta.get_all_field_names()
user = User.objects.get(email='email')
profile = Profile.objects.get(user__email='email')
assert == ==
assert == 'email'
assert profile.user.first_name == 'firstname'
assert profile.user.last_name == 'lastname'
Copy link

fernandogrd commented Aug 7, 2015

Very helpful, thanks!
I did a unittest version, similar to

# coding: utf-8

from django.db import connection
from django.db.migrations.executor import MigrationExecutor
from django.test.testcases import TransactionTestCase

class MigrationTestCase(TransactionTestCase):
    '''A Test case for testing migrations'''

    # These must be defined by subclasses.
    migrate_from = None
    migrate_to = None

    def setUp(self):
        super(MigrationTestCase, self).setUp()

        self.executor = MigrationExecutor(connection)

    def migrate_to_dest(self):
        self.executor.loader.build_graph()  # reload.

    def old_apps(self):
        return self.executor.loader.project_state(self.migrate_from).apps

    def new_apps(self):
        return self.executor.loader.project_state(self.migrate_to).apps

class FooTestCaseCase(MigrationTestCase):

    migrate_from = [('app_name', "000X_before")]
    migrate_to = [('app_name', "000X_after")]

    def test_migration(self):
        # Setup code
        Profile = self.old_apps.get_model('account', "Profile")


        Profile = self.new_apps.get_model('account', "Profile")

        # assertions

Copy link

ghost commented Mar 21, 2016

Copy link

bendholmes commented May 3, 2016

Just a note for anyone thinking of using the code from, it doesn't work on Django 1.9 (haven't tried other versions). More specifically the data entered before the migration ran simply isn't available to the migration at all.

Copy link

cjw296 commented Oct 6, 2016

Why not have old_apps and new_apps set in self.setUp() rather than executing them every time they're accessed?

Copy link

asfaltboy commented Jan 27, 2017

I added a "reusable" pytest fixture over here:

Copy link

lingxiaoyang commented Mar 8, 2017

Note: the code in this article misses the following line:


If, let's say, you create a table in the migration, you'll need this line to work properly otherwise Django will prompt django.db.utils.OperationalError: no such table

Copy link

TauPan commented Apr 7, 2017

I've updated @asfaltboy's pytest fixture for django 1.8, pytest==3.0.7, pytest-django==3.1.2. At least I had problems with it which are fixed in my version:

Copy link

Pomax commented May 26, 2017

I tried using the medium post code, but ended up constantly getting django.db.migrations.exceptions.NodeNotFoundError: Node ('mysite.myapp', '0006_auto_20170525_2235') not a valid node when calling things like Entry = apps.get_model('mysite.myapp', 'Entry') with a migrate_from = '0006_auto_20170525_2235' (which exists as file in the migrations dir)

Copy link

ghost commented Jul 4, 2017

I have the same problem as @Pomax 😕

Copy link

ghost commented Jul 4, 2017

Never mind. I think that it's because of the fact that I have migrations disabled in my file..


Copy link

Pycz commented Jul 25, 2017

What to do if I have not reversible migrations? How to prevent migrations before tests?

Copy link

legshort commented Sep 20, 2017

If you want to disable all migrations for regular test code and also want to test migration scenario, you can try this.
Any feedback would be welcome and I explained this at
The code base is here


class TestMigrations(TestCase):
    origin_modules = getattr(settings, 'MIGRATION_MODULES', {})
    setattr(settings, 'MIGRATION_MODULES', {})

    def tearDownClass(cls):
        setattr(settings, 'MIGRATION_MODULES', cls.origin_modules)

Copy link

asfaltboy commented May 8, 2018

Thanks @TauPan your version worked for me on Django 2.0 too.

Unfortunately, there is no support for pytest.raises for exceptions that occur during migrations, and possibly other issues, let's try to discuss it over at pytest-dev/pytest-django#593

EDIT: I used @TauPan's updates (Gist-spection!) and cleaned my own fork a bit and allowed specifying a list of target migrations (when conditions span across multiple apps).

Copy link

sobolevn commented Nov 25, 2019

I have made a pypi package out of this gist with some extra features.
Check it out:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment