>
> Actually, if I may ask, how else would one load bunches of fixtures in the
> DB and run tests in parallel without my PR ?
>
As I said, register a post_migrate handler during testing that loads your
data. It will run during the creation of the first database in
connection.creation.create_test_d
I believe I was not clear.
I do use migrations to populate Enums and other data that should also be
available in production.
The code I am sending is to load fixtures on the database.
This way all tests can assume the same set of data and we all the fixtures
are loaded in one place, which in m
Avoiding migrations, one can populate test data with a post_migrate signal
handler. django.contrib.contenttypes already does this to fill the DB with
content types, see
https://github.com/django/django/blob/c651331b34b7c3841c126959e6e52879bc6f0834/django/contrib/contenttypes/apps.py#L18
. To do it
On Saturday 29 April 2017 03:50:16 Tim Graham wrote:
> I would expect test data population to happen using migrations rather than
> in the test runner. Can you elaborate on your use case and say if that
> method would be unsuitable?
>
Apparently, many people think that migrations are the wrong to
I would expect test data population to happen using migrations rather than
in the test runner. Can you elaborate on your use case and say if that
method would be unsuitable?
On Friday, April 28, 2017 at 8:45:55 PM UTC-4, Marcos Diez wrote:
>
> Ticket:https://code.djangoproject.com/ti
Ticket:https://code.djangoproject.com/ticket/28153
Pull Request: https://github.com/django/django/pull/8437
Although Django makes very easy for one to extend
django.test.runner.DiscoverRunner
, it's setup_databases() does too much.
Currently, it
- creates all the test databases
