On Sat, Mar 8, 2008 at 3:09 AM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-03-07 at 09:58 -0800, meppum wrote:
> > I've been playing with Django for a while now, learning the ropes and
> > such. I started building some unit tests using the django TestCase
> > classes, but recently I've hit a snag with using Postgres as the
> > backend to my tests and testing database exceptions.
>
> Before anybody points this back to django-users, I asked Meppum to post
> here. It requires some design work. Because the test framework uses a
> single database connection throughout, it's not too hard to trip it up,
> so we need to think about where the boundaries are and what people need
> to do in their tests (plus, whether we're missing some support
> internally).
I agree that this is a nasty little edge case; any situation where an
error in one test corrupts all subsequent tests is something that
would be good to avoid at a framework level, if possible.
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()
However, I can't think of any obvious way to perform this test. It
might be possible to hack a solution by performing a low-cost no-op
SQL query and checking for an exception. Suggestions welcome.
Yours,
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
