On Sun, 2008-03-09 at 05:42 -0700, kent wrote: > On Mar 9, 3:52 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> > wrote: > > That said, I'm not sure there is much we can do about it. It isn't as > > simple as wrapping the test case with a try/except block; if you are > > explictly testing error states, or the last SQL query in a test is the > > statement that causes a problem, there won't be an exception to catch. > > Essentially what we need in the tearDown is logic that tests: > > > > if cursor is in erroneous state: > > transaction.rollback() > > That is not really adequate. The rollback() needs to occur immediately > after the assertion that causes the error so an > assertRaises(DatabaseError, ... > can be followed by an assertion that is expected to succeed.
Or the test in question needs to be redesigned so that it's only testing one thing at a time if you're going to rely on automatic rollback. If you want to test in-function error recovery, you're going to have to do the rollback yourself, just like in normal code. The issue in question here is the isolation between tests, not within a single test. Malcolm -- For every action there is an equal and opposite criticism. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
