I'd parked this problem for quite some time, until it finally became
incontestably necessary to wrestle the issue to the ground.
What I found, after many hours of experimenting - too much like the random
walk, I suppose, is that every time I overrode setUpClass, I also had to
override tearDownClass. Before, if I had nothing to clean up after the
test, I wouldn't bother overriding tearDownClass.
When I went to all my tests and added
@classmethod
def tearDownClass(cls):
pass
Then my problems went away. I reckon that's in the docs somewhere. But it
seems to me that tearDownClass should be able to degrade more gracefully.
:weary:
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/48645d77-8c7d-46aa-82fc-24ea98153190%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
