Opened 3 years ago

Last modified 2 months ago

#21143 new Bug

runtests might execute queries against the normal database instead of the testdatabase

Reported by: Florian Apolloner Owned by: nobody
Component: Testing framework Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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/", line 384, in _executeTestPart
  File "/usr/lib/python3.3/unittest/", 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/", 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/", 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/", 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/", 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/", 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/", 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/", line 296, in _do_query
_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.

Change History (5)

comment:1 Changed 3 years ago by Pablo SEMINARIO

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.

comment:2 Changed 3 years ago by Florian Apolloner

There is no need for a testproject, since this can be exposed by Django's testsuite itself… See the current fix in (I refed the ticket there, but apperently trac didn't pick it up)

comment:3 Changed 3 years ago by Pablo SEMINARIO

Oh OK, my mistake, now I understand, "our testrunner" is the Django's testrunner. I'll check the fix.

comment:4 Changed 2 months ago by Tim Graham

Florian, are there any other action items for this ticket?

comment:5 Changed 2 months ago by Florian Apolloner

Yeah, we might check if we can delay test discovery till settings are configured properly (ie for testing)

Last edited 2 months ago by Florian Apolloner (previous) (diff)
Note: See TracTickets for help on using tickets.
Back to Top