1.7 to 1.8 upgrade: test suite failing

[tom.sz...@eporta.com]

Hi,

I've recently tried upgrading from Django 1.7.6 to 1.8.3 but haven't been able to get my test suite to pass.

My main problem is that all of the tests pass when run individually, but when run as an entire test suite, many arbitraily fail due to an InterfaceError: connection already closed:

  File "/usr/local/lib/python2.7/dist-packages/django/db/models/sql/compiler.py", line 838, in execute_sql
    cursor = self.connection.cursor()
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 164, in cursor
    cursor = self.make_cursor(self._cursor())
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 137, in _cursor
    return self.create_cursor()
  File "/usr/local/lib/python2.7/dist-packages/django/db/utils.py", line 97, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 137, in _cursor
    return self.create_cursor()
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/postgresql_psycopg2/base.py", line 212, in create_cursor
    cursor = self.connection.cursor()
InterfaceError: connection already closed

I was previously using psycopg2.6 with Postgres 9.3 and have tried upgrading to psycopg2.6.1 with Postgres 9.4, but this hasn't helped.

Forcing all my TestCase classes to inherit from SimpleTestCase resolves this issue, but inheriting from SimpleTestCase isn't something that I wish to do.

Any help would be much appreciated.

Thanks,

Tom

[Tim Graham]

No ideas, but if you could bisect to find the Django commit where the problem started to appear that will probably help.

[tom.sz...@eporta.com]

Thanks for the swift reply. The problem starts with Django 1.8.0. My test suite passes on all 1.7.x versions.

[Tim Graham]

That's a starting point, but there are still a lot of commits between 1.8 and 1.7.x. Here's what I meant by "bisecting the commit":

https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#bisecting-a-regression

[tom.sz...@eporta.com]

Thanks for the link.
This is the commit at which my tests start failing:
da9fe5c Fixed #20392 -- Added TestCase.setUpTestData()

[Tim Graham]

Do your test classes use setUpClass() and/or tearDownClass()? If so, are you missing super() calls in those methods?

On Monday, July 13, 2015 at 9:37:03 AM UTC-4, tom.sz...@eporta.com wrote:

Thanks for the link

[tom.sz...@eporta.com]

Hi, yes. Some of my test classes do use setUpClass() without calling super().

[Tim Graham]

Please try adding the super() calls.

[tom.sz...@eporta.com]

Unfortunately, adding the super() calls didn't help.

[Tim Graham]

A minimal project to reproduce the issue would be helpful.

[simon.s...@eporta.com]

Hi Tim,

Thanks again for the responses. Tom is now on holiday for a week but we'll pick up where he left off and try to replicate the issue in a minimal project.

Cheers,

Simon

[simon.s...@eporta.com]

Hi Tim,

Thanks again for your help and sorry for the long delay. We've now solved the issue but I'd like to share the changes we made. I'm not sure which are essential and they're all in the RTFM category, however, they might serve as useful pointer to someone:

1. Make sure the TestCase version of test lifecycle methods is *always* run (setUpTestData, setUp etc.). Be careful with any mixins or missing super() calls that might be circumventing the TestCase version of the method (it seems like you could get away with this in 1.7 but not 1.8)
2. Avoid setUpClass, use setUpTestData instead
3. Don't mix django TestCase and unittest.TestCase in the same suite. Use SimpleTestCase where you need a lightweight test.
4. If a test spawns threads that need to access the database data, use TransactionalTestCase, not TestCase.
5. RTFM: https://docs.djangoproject.com/en/1.8/topics/testing/tools/

Thanks again,

Simon