Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#18402 closed Bug (wontfix)

`DjangoTestSuiteRunner().setup_databases()` fails on second exercise

Reported by: David Eyk <deyk@…> 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 David Eyk <deyk@…>, 13 years ago

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 the teardown_databases code from Django 1.3 but this does not seem to do any good. :(

comment:2 by Anssi Kääriäinen, 13 years ago

Resolution: wontfix
Status: newclosed

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 David Eyk <deyk@…>, 13 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.

Note: See TracTickets for help on using tickets.
Back to Top