#10868: _destroy_test_db exposes the production database to possibly destructive
actions from the unit tests
-------------------------------------+-------------------------------------
Reporter: ovidiu | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version:
Severity: Release blocker | Resolution:
Keywords: django.test | Triage Stage: Design
Has patch: 0 | decision needed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by akaariai):
I was going to ask the same question about testing this :) I think it is
possible to write a tester script (so that it is possible to confirm
manually everything is fine), but including it in the test-suite seems
problematic. I do not know a way to do that. Maybe setup a fake test
runner + some threads, then call .teardown_databases with empty old_config
and see that it does the proper thing. The right place for the check seems
to be as the first thing in teardown_databases.
My proposal about the timeout is that if the threads haven't quit after
the timeout, then do not try to destroy the testdb. Throw an error
instead. Notably, there is no risk to the production database, because if
the threads can't be joined, we would NOT change the connection settings
back to the production settings. We would just quit & leave the testdb in
there.
--
Ticket URL: <https://code.djangoproject.com/ticket/10868#comment:11>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
