[Django] #21143: runtests might execute queries against the normal database instead of the testdatabase
Django
testdatabase
---------------------------------------------+------------------------
Reporter: apollo13 | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Severity: Normal | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
---------------------------------------------+------------------------
The way our testrunner currently works is that it constructs the test
classes before creating the test database and resetting the database
names. This causes module level queries (which you shouldn't have, but…)
to be executed against the main database resulting in errors like:
{{{
Traceback (most recent call last):
File "/usr/lib/python3.3/unittest/case.py", line 384, in
_executeTestPart
function()
File "/usr/lib/python3.3/unittest/loader.py", line 32, in testFailure
raise exception
ImportError: Failed to import test module: transactions_regress.tests
Traceback (most recent call last):
File
"/var/lib/jenkins/jobs/Django/workspace/database/mysql_gis/python/python3.3/django/db/utils.py",
line 101, in inner
return func(*args, **kwargs)
File
"/var/lib/jenkins/jobs/Django/workspace/database/mysql_gis/python/python3.3/django/db/backends/mysql/base.py",
line 131, in execute
return self.cursor.execute(query, args)
File "/usr/local/lib/python3.3/dist-packages/MySQL_python-1.2.3-py3.3
-linux-x86_64.egg/MySQLdb/cursors.py", line 185, in execute
self.errorhandler(self, exc, value)
File "/usr/local/lib/python3.3/dist-packages/MySQL_python-1.2.3-py3.3
-linux-x86_64.egg/MySQLdb/connections.py", line 37, in defaulterrorhandler
raise errorvalue
File "/usr/local/lib/python3.3/dist-packages/MySQL_python-1.2.3-py3.3
-linux-x86_64.egg/MySQLdb/cursors.py", line 172, in execute
r = self._query(query)
File "/usr/local/lib/python3.3/dist-packages/MySQL_python-1.2.3-py3.3
-linux-x86_64.egg/MySQLdb/cursors.py", line 332, in _query
rowcount = self._do_query(q)
File "/usr/local/lib/python3.3/dist-packages/MySQL_python-1.2.3-py3.3
-linux-x86_64.egg/MySQLdb/cursors.py", line 296, in _do_query
db.query(q)
_mysql_exceptions.OperationalError: (1050, "Table 'INTROSPECT_TEST'
already exists")
}}}
In the case above this is caused by two parallel testruns against
different TEST_NAMEs but the same NAME in the database config. It would be
nice if we could fix that.
--
Ticket URL: <https://code.djangoproject.com/ticket/21143>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
testdatabase
Reporter: apollo13 | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by pabluk):
Can you provide a minimal test project (settings and your testrunner) in
which the queries are executed again the normal database?
So that the problem can be reproduced and investigated.
--
Ticket URL: <https://code.djangoproject.com/ticket/21143#comment:1>
Django
testdatabase
Reporter: apollo13 | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by apollo13):
There is no need for a testproject, since this can be exposed by Django's
testsuite itself… See the current fix in
https://github.com/django/django/commit/4fcc1e4ad8d153f41132b171c231b6d5d4086c28
(I refed the ticket there, but apperently trac didn't pick it up)
--
Ticket URL: <https://code.djangoproject.com/ticket/21143#comment:2>
Django
testdatabase
Reporter: apollo13 | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by pabluk):
Oh OK, my mistake, now I understand, ''"our testrunner"'' is the Django's
testrunner. I'll check the fix.
--
Ticket URL: <https://code.djangoproject.com/ticket/21143#comment:3>
Django
testdatabase
Reporter: apollo13 | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
Florian, are there any other action items for this ticket?
--
Ticket URL: <https://code.djangoproject.com/ticket/21143#comment:4>
Django
testdatabase
Reporter: apollo13 | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by apollo13):
Yeah, we might see if we can delay test discovery till settings are
configured properly (ie for testing)
--
Ticket URL: <https://code.djangoproject.com/ticket/21143#comment:5>
Django
testdatabase
Reporter: Florian Apolloner | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: dev
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Ülgen Sarıkavak):
* cc: Ülgen Sarıkavak (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/21143#comment:6>