Trac #7835: Test only models doc #4700

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
3 participants
@khoobks

khoobks commented May 23, 2015

The following pull request is purely to add some documentation on how to add models that will only get created during unit tests.

Trac Ticket: https://code.djangoproject.com/ticket/7835

One concern that I have is that I have added this below Using the Django test runner to test reusable applications. To me, I feel that both sections are talking about different ways of creating test only models but I understand if the community feels that this is a duplicate.

khoobks added some commits May 23, 2015

@khoobks khoobks changed the title from Test only models doc to Trac #7835: Test only models doc May 24, 2015

@timgraham

This comment has been minimized.

Show comment
Hide comment
@timgraham

timgraham May 25, 2015

Member

Thanks for tackling this, however, I'm not convinced we should document this approach. I left some thoughts on the ticket.

Member

timgraham commented May 25, 2015

Thanks for tackling this, however, I'm not convinced we should document this approach. I left some thoughts on the ticket.

@khoobks

This comment has been minimized.

Show comment
Hide comment
@khoobks

khoobks May 26, 2015

Agreed. A sanctioned way to tackle this is a better approach than a workaround. Do you know if there are any plans for such a decorator in the works?

khoobks commented May 26, 2015

Agreed. A sanctioned way to tackle this is a better approach than a workaround. Do you know if there are any plans for such a decorator in the works?

@khoobks khoobks closed this May 26, 2015

@timgraham

This comment has been minimized.

Show comment
Hide comment
@timgraham

timgraham May 26, 2015

Member

I'm not aware of any discussion of the issue outside of the ticket.

Member

timgraham commented May 26, 2015

I'm not aware of any discussion of the issue outside of the ticket.

@khoobks

This comment has been minimized.

Show comment
Hide comment
@khoobks

khoobks May 26, 2015

Roger. Thanks for taking the time to look at the PR and for your comments.

khoobks commented May 26, 2015

Roger. Thanks for taking the time to look at the PR and for your comments.

+
+The ``models.py`` file in the test module contains your test-only model definitions. It is important to leave the original ``models.py`` file in the app module even if it is empty.
+
+Create a migration for your test-models in the migrations module. You will need to adapt the migration to only execute during unit tests. You can do this by checking the database name::

This comment has been minimized.

@alex-hutton

alex-hutton Aug 13, 2015

What do you mean by creating the migration in the migrations module? Are you saying put it in migrations/__init__.py?

@alex-hutton

alex-hutton Aug 13, 2015

What do you mean by creating the migration in the migrations module? Are you saying put it in migrations/__init__.py?

This comment has been minimized.

@khoobks

khoobks Aug 13, 2015

Create the migration (python file) inside the migrations folder just like any other migration. e.g polls/migrations/0002_add_test_models.py

@khoobks

khoobks Aug 13, 2015

Create the migration (python file) inside the migrations folder just like any other migration. e.g polls/migrations/0002_add_test_models.py

This comment has been minimized.

@alex-hutton

alex-hutton Aug 14, 2015

Thanks, so you're saying to create a normal migration in the migration chain, but with the conditional that prevents migration except in tests.so in your example, 0002_add_test_models.py would depend on the previous 0001 migration and the subsequent 0003 migration would depend on 0002_add_test_models. And inevitably this migration would be squashed into the others.

@alex-hutton

alex-hutton Aug 14, 2015

Thanks, so you're saying to create a normal migration in the migration chain, but with the conditional that prevents migration except in tests.so in your example, 0002_add_test_models.py would depend on the previous 0001 migration and the subsequent 0003 migration would depend on 0002_add_test_models. And inevitably this migration would be squashed into the others.

This comment has been minimized.

@khoobks

khoobks Aug 14, 2015

Yes 0002 will go into the migration chain after 0001 and before 0003. In the normal migration sequence, it will essentially be a noop ("no operation") because the real database will not start with 'test_'. In the migration sequence during unit tests however, the database will start with 'test_' and therefore migration 0002 will actually run and create tables for your test models.

I am not sure about what effect squashing migrations will have on this.

@khoobks

khoobks Aug 14, 2015

Yes 0002 will go into the migration chain after 0001 and before 0003. In the normal migration sequence, it will essentially be a noop ("no operation") because the real database will not start with 'test_'. In the migration sequence during unit tests however, the database will start with 'test_' and therefore migration 0002 will actually run and create tables for your test models.

I am not sure about what effect squashing migrations will have on this.

+
+ def is_test_db():
+ return settings.DATABASES.get(
+ 'default', {}).get('NAME', '').startswith('test_')

This comment has been minimized.

@alex-hutton

alex-hutton Aug 14, 2015

I'm using sqlite and the DATABASES['default']['NAME'] was ':memory:'.

@alex-hutton

alex-hutton Aug 14, 2015

I'm using sqlite and the DATABASES['default']['NAME'] was ':memory:'.

This comment has been minimized.

@khoobks

khoobks Aug 14, 2015

I can't comment specifically about what Django does with SQLite in memory databases. I am just going from what the documentation says on database naming here https://docs.djangoproject.com/en/1.8/topics/testing/overview/#the-test-database

I have only ever used this technique on a postgres database.

@khoobks

khoobks Aug 14, 2015

I can't comment specifically about what Django does with SQLite in memory databases. I am just going from what the documentation says on database naming here https://docs.djangoproject.com/en/1.8/topics/testing/overview/#the-test-database

I have only ever used this technique on a postgres database.

chosak added a commit to cfpb/cfgov-refresh that referenced this pull request Aug 25, 2016

fix tests by removing test-only models
Unfortunately Django doesn't make it easy to use test-only models, so
instead of simply doing this, I have to use some existing real model.
Here I chose to use django.contrib.auth.models as it's a safe bet that
it exists, but it's still not ideal to have this external dependency.

See this Django issue for more info on why this is needed:

django/django#4700/

chosak added a commit to cfpb/cfgov-refresh that referenced this pull request Aug 26, 2016

fix tests by removing test-only models
Unfortunately Django doesn't make it easy to use test-only models, so
instead of simply doing this, I have to use some existing real model.
Here I chose to use django.contrib.auth.models as it's a safe bet that
it exists, but it's still not ideal to have this external dependency.

See this Django issue for more info on why this is needed:

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