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
On Monday, July 20, 2015 at 11:03:42 AM UTC+1, simon.s...@eporta.com wrote:
-- 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
On Monday, July 20, 2015 at 11:03:42 AM UTC+1, simon.s...@eporta.com wrote:
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
On Wednesday, July 15, 2015 at 3:03:31 PM UTC+1, Tim Graham wrote:A minimal project to reproduce the issue would be helpful.
On Wednesday, July 15, 2015 at 5:41:49 AM UTC-4, tom.sz...@eporta.com wrote:Unfortunately, adding the super() calls didn't help.
On Tuesday, July 14, 2015 at 12:47:02 PM UTC+1, Tim Graham wrote:Please try adding the super() calls.
On Tuesday, July 14, 2015 at 5:44:09 AM UTC-4, tom.sz...@eporta.com wrote:Hi, yes. Some of my test classes do use setUpClass() without calling super().
On Monday, July 13, 2015 at 5:44:03 PM UTC+1, Tim Graham wrote: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
This is the commit at which my tests start failing:
da9fe5c Fixed #20392 -- Added TestCase.setUpTestData()
On Monday, July 13, 2015 at 12:39:57 PM UTC+1, Tim Graham wrote: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
On Monday, July 13, 2015 at 5:50:49 AM UTC-4, tom.sz...@eporta.com wrote:Thanks for the swift reply. The problem starts with Django 1.8.0. My test suite passes on all 1.7.x versions.
On Friday, July 10, 2015 at 2:32:25 PM UTC+1, Tim Graham wrote:No ideas, but if you could bisect to find the Django commit where the problem started to appear that will probably help.
On Friday, July 10, 2015 at 7:21:37 AM UTC-4, tom.sz...@eporta.com wrote: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/ , line 838, in execute_sqlmodels/sql/compiler.py"
cursor = self.connection.cursor()
File "/usr/local/lib/python2.7/dist-packages/django/db/ , line 164, in cursorbackends/base/base.py"
cursor = self.make_cursor(self._cursor())
File "/usr/local/lib/python2.7/dist-packages/django/db/ , line 137, in _cursorbackends/base/base.py"
return self.create_cursor()
File "/usr/local/lib/python2.7/dist-packages/django/db/utils. , line 97, in __exit__py"
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/usr/local/lib/python2.7/dist-packages/django/db/ , line 137, in _cursorbackends/base/base.py"
return self.create_cursor()
File "/usr/local/lib/python2.7/dist-packages/django/db/ , line 212, in create_cursorbackends/postgresql_psycopg2/ base.py"
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
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/e7b929d7-2134-485f-8f0d-6c462edfb795%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment