id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
28153	patch: it's now easier to populate data databases in test databases that run code in parallel	Marcos Diez	nobody	"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 (for single thread unit tests)
- duplicates all the test databases (in case of parallel unit tests)

In case I am running not running tests in parallel, I can just populate the DB after running unit tests without any issues.

But if I care about my time and want to run tests in parallel, I can either:

a) populate my data after setup_databases() is executed, once for each thread of the parallel tests, which is slow
b) get my hands dirty and reimplement ` setup_databases() `

I propose (and I am sending the code to do so) a better solution. We just have to break `setup_databases()` in 3 functions:

`DiscoverRunner.prepare_databases() `
`DiscoverRunner.populate_databases() # noop by default `
`DiscoverRunner.duplicate_databases_if_necessary()`


The idea is quite simple: in order to be backward compatible, ` setup_databases() `, will still exist but only call three functions above in that order.

The first function will create all the test databases necessary for non parallel tests to run.

` populate_databases() `, which should be a no op, can be overwritten by the user who  extends ` django.test.runner.DiscoverRunner ` so his/her data can be populated 

Afterwards, all the test DBs are copied as many times as necessary in case parallel tests are run via ` DiscoverRunner.duplicate_databases_if_necessary() `


I believe this change on Django will have no downside, will be backward compatible and help people who needs to populate real data on the DB for their tests.








"	New feature	new	Testing framework	dev	Normal				Unreviewed	1	0	0	0	0	0