Opened 7 years ago
Closed 7 years ago
#28320 closed Cleanup/optimization (duplicate)
Parallel testing: Please implement a signal or call checks after test DB creation but before cloning it.
Reported by: | László Károlyi | Owned by: | nobody |
---|---|---|---|
Component: | Testing framework | Version: | 1.11 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Hi,
I tried to reach someone on IRC, but actually it's better to document my issue here, maybe there will be a solution to it eventually.
I'm trying to use the new and shiny parallel testing functionality of Django 1.11, and I've run into problems with it.
So I have functionality implemented on check
and the post_migrate
signal, where I conditionally insert stuff into the DB that can't be inserted by fixtures, and also conditionally modify DB fields that can't be done from the ORM. (the latter is basically changing collation on a column)
It seems that the post_migrate signal is run randomly before and after the test creation, and checks are only run *after* the DB is cloned, so I don't have a sufficient point where I can have my logic run.
Monkey-patching has shown that the best solution would be to run call_command('check')
here, so basically after create_test_db
but before clone_test_db
.
I can quickly add that, but I'm not sure how it could be tested, and what implications it would have, so I'm asking you guys, if you think it's doable and feasible. Because of this right now, I can't use parallel testing.
Change History (3)
follow-up: 3 comment:2 by , 7 years ago
comment:3 by , 7 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Update:
It seems I managed to consistently insert the needed data into the DB before it gets cloned by subclassing the testrunner and running checks before
setup_databases()
runs. But that brought another problem I discovered, and which maybe could be fixed.So the first part I'm doing at startup is, I update my own permission models, which subclass the original django
Permission
model. Formerly, I had a function that would give aContentType
model ofdjango.contrib.auth
:Because
ContentType.objects.get_for_model()
caches, and because the nature of the parallel testing, that cached result sometimes brought models with wrongID
s, and I got constraint violations because no such IDs existed in my DB.I fixed my code by not using
get_for_model()
, and usingget()
instead. I'm just leaving this information here for your consideration.