Why do migrations fail on test, but not on migrate? - django-testing

Question

I'm using Django==1.7, and have four applications:
frontend
game
geo
people
The apps settings is like this:
INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'fandjango',
'people',
'geo',
'game',
'frontend'
)
And the database settings are:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'hoods_raising',
'USER': 'hoods_raising',
'PASSWORD': 'hr$nestor$123',
'HOST': 'localhost',
'TEST_CHARSET': 'utf8mb4'
}
}
My applications have migrations and tests:
game
migrations
0001_initial.py
geo
migrations
0001_initial.py
tests.py
people
migrations
0001_initial.py
0002_install_data.py
Many files were omitted to narrow the problem (I'll expand the question with more files if needed), e.g. models.py, views.py.
The contents of 0002_install_data.py are:
class Migration(migrations.Migration):
dependencies = [
('people', '0001_initial'),
]
operations = [
migrations.RunPython(NamesInstaller(), lambda apps, schema_editor: None)
]
If I run manage.py migrate to install the database, everything works as expected.
If I run manage.py test to run the tests, the first step will be the test database installation. Something weird happens:
The first migration to be executed is 0002_install_data. Other tables are never created (e.g. auth tables, geo tables, game tables, fandjango tables, ...) and migration 0001_initial in people is not run.
For such reason, A dependency error occurs in 0002_install_data (it says that 0001_initial does not exist).
KeyError: u"Migration people.0002_install_data dependencies references nonexistent parent node (u'people', u'0001_initial')"
Why could this be happening? Why wouldn't the test command not arrange correctly the application migrations? (this does not happen on manage.py migrate).

Answer 1

I solved it. That issue appeared because I messed with Squashed migrations: since I did not deploy this beforehand to a productive environment I took the freedom to delete the replaced migrations (and only keep the squashed).
When you delete the replaced migrations and keep the squashed and then do migrate, everything will work as expected. However the squashed migration will reference the replaced migrations if you run the tests and so it will fail.
Unfortunately, I named the squashed migration 0001_initial, like the first migration, which mislead me to think it was a dependency problem with an existent file.
So: If you want to squash a migration ensure you know what you're doing and don't delete previous migrations unless:
You know nobody will use them again (i.e. no instance is "in the middle" of the squashed migration path).
You DELETE the replacement directive in the squashed migration. Otherwise tests will fail because database will not be able to setup.