#18402 closed Bug (wontfix)
`DjangoTestSuiteRunner().setup_databases()` fails on second exercise
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Testing framework | Version: | 1.4 |
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
I'm using Behave (http://packages.python.org/behave/) to test Django. I'm exercising the DjangoTestSuiteRunner manually to setup and teardown the test environment around test scenarios. (See the complete working example at this gist: https://gist.github.com/1637965 -- the test runner stuff is in features/environment.py, specifically before_scenario():74
and after_scenario():93
).
This technique worked perfectly on Django 1.3.1, but after switching to 1.4, it has begun to fail while setting up the database for the second scenario, with the following traceback:
Destroying test database for alias 'default'... Creating test database for alias 'default'... Traceback (most recent call last): File "/Users/deyk/code/py/1637965/bin/behave", line 5, in <module> main() File "/Users/deyk/code/py/1637965/lib/python2.7/site-packages/behave/__main__.py", line 90, in main failed = runner.run() File "/Users/deyk/code/py/1637965/lib/python2.7/site-packages/behave/runner.py", line 419, in run self.run_with_paths() File "/Users/deyk/code/py/1637965/lib/python2.7/site-packages/behave/runner.py", line 444, in run_with_paths failed = feature.run(self) File "/Users/deyk/code/py/1637965/lib/python2.7/site-packages/behave/model.py", line 238, in run failed = scenario.run(runner) File "/Users/deyk/code/py/1637965/lib/python2.7/site-packages/behave/model.py", line 425, in run runner.run_hook('before_scenario', runner.context, self) File "/Users/deyk/code/py/1637965/lib/python2.7/site-packages/behave/runner.py", line 398, in run_hook self.hooks[name](context, *args) File "/Users/deyk/code/py/1637965/features/environment.py", line 82, in before_scenario context.old_db_config = context.runner.setup_databases() File "/Users/deyk/code/py/1637965/lib/python2.7/site-packages/django/test/simple.py", line 317, in setup_databases self.verbosity, autoclobber=not self.interactive) File "/Users/deyk/code/py/1637965/lib/python2.7/site-packages/django/db/backends/creation.py", line 256, in create_test_db self._create_test_db(verbosity, autoclobber) File "/Users/deyk/code/py/1637965/lib/python2.7/site-packages/django/db/backends/creation.py", line 321, in _create_test_db cursor = self.connection.cursor() File "/Users/deyk/code/py/1637965/lib/python2.7/site-packages/django/db/backends/__init__.py", line 308, in cursor cursor = util.CursorWrapper(self._cursor(), self) File "/Users/deyk/code/py/1637965/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py", line 177, in _cursor self.connection = Database.connect(**conn_params) psycopg2.OperationalError: FATAL: database "test_myproject" does not exist
I'm using the postgresql_psycopg2 engine, with a psycopg2 version of 2.4.5 (the latest as of this writing). I do not encounter this error when switching to the sqlite3 engine. I've also tested the example project with psycopg2 all the way down to 2.3, with the same error. The example project tests fine with Django 1.3.1 and psycopg2 2.4.1 (2.4.2 introduces an unrelated bug in the Django 1.3.x line).
To reproduce this error, create a Postgres login role with u: myuser
, p: mypassword
, and a db of myproject
, then:
git clone git://gist.github.com/1637965.git cd 1637965 virtualenv . source bin/activate pip install -r requirements.txt behave
Change History (3)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
You likely aren't using the TestRunner in any publicly documented way. Still, it would be nice to know what the exact issue here is. The commit that did the change to the database restoring after the tests is this: f1dc83cb9877d349df88674a0752ddf42657485b. The commit contains some stylistic cleanup, too, so you will need to read it carefully to see the actual changes.
It seems pretty clear you are in fact hitting the issue mentioned in the release notes - it seems you are trying to connect to the test database after the first run, but that one is dropped. I would just call super() and then go through all the connections in the overriding method and make sure all connections have NAME set to the pre-test setting.
I am marking this one wontfix. If it seems there is need for some release note changes or that the code in fact isn't backwards compatible, then reopen this ticket.
comment:3 by , 12 years ago
Yeah, I figured. :) My usage is definitely a result of reverse-engineering the test runner, rather than reading the docs. Thanks for the pointer to the commit in question--that will be helpful. I'll update this ticket if I find anything that might need your action.
I saw a note in the 1.4 release notes on database connections not getting restored after running a test suite, and tried subclassing
django.test.simple.DjangoTestSuiteRunner
and restoring theteardown_databases
code from Django 1.3 but this does not seem to do any good. :(