Matt S
Matt S

Reputation: 43

When I run python manage.py test... only some of my tables / fields are created in the test db

In django, I am trying to run tests on a test db, but I can't seem to get the test db stood up properly...

I have 226 models on my real db, but when I run python manage.py test (test location) it breaks pretty quickly referencing that a field is not present in the test db.

    Creating test database for alias 'default'...
Traceback (most recent call last):
  File "C:\Users\msullivan\Django_Projects\myscore-v2\myvenv\lib\site-packages\django\db\backends\utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)
psycopg2.errors.UndefinedColumn: column core_division.display_name does not exist
LINE 1: ..., "core_division"."slug", "core_division"."name", "core_divi...

A quick look at the test db (since it crashes, it doesn't teardown the db, so I can view it) shows only 47 tables created, and sure enough that particular field is not there.

Below is my database settings in my config.settings.test file:

DATABASES = {
'default': {
    'ENGINE': 'django.db.backends.postgresql_psycopg2',
    'NAME': 'myscore',
    'USER': env('DEFAULT_DATABASE_USER'),
    'PASSWORD': env('DEFAULT_DATABASE_PASSWORD'),
    'HOST': 'localhost',
    'PORT': '',
    'TEST': {
        # 'MIRROR': 'default',
        'SERIALIZE': False,
        # 'MIGRATE': False,
    }
},
}

What I tried to do as a workaround was apply the 'MIGRATE': False option.

When I do this (with --keepdb applied), I see that the test db has 195 tables (and does have the field that wasn't created before). So this is better. No failures / crashes.

However...I can't seem to write / read anything from the db and I'm not sure why...

So...what I've been doing is turning on 'MIRROR': 'default' which seems like it does NOT spin up a test db, and writes / reads from my real database...which obviously is not ideal...but can't seem to get the test db to work correctly.

Any idea on what is happening / how I can get the test db to spin up correctly and subsequently allow me to write to it?

Upvotes: 0

Views: 88

Answers (2)

Matt S
Matt S

Reputation: 43

I found out my issue was partially due to the fact that there were some data migration files that were conditioned to not run if 'test' was in sys.argv. AKA when I run python manage.py test ...So they were getting skipped over when building the test db.

I updated them so that they would get picked up, however another issue occurred related to a data migration.

A lot of our migrations were referncing models directly, which I think is part of the issue. From researching I think you're supposed to use app.get_model() in migration files because it references the data at that point in time? In any case...the issue with my test db not spinning up correctly is due to multiple migration file issues. It doesnt seem worthwhile to try and address all of it, so I will probably use MIGRATE: False to skip this.

Upvotes: 0

Dave
Dave

Reputation: 996

It's hard to know without a full stack trace, but it's likely you have missing migrations. Please check:

  • All your Django apps have a migrations folder.
  • Running ./manage.py makemigrations doesn't create any new migrations. If it does... commit them!

If you could update your question will a full stack trace, I might be able to offer a better diagnosis! 🙇

Upvotes: 0

Related Questions