On Sun, Oct 19, 2008 at 5:06 PM, zobbo <[EMAIL PROTECTED]> wrote: > > When a test fails and another test then runs, it dies because the > transaction is in error. The field with too many chars fails and that > causes the next test to raise an error. If you switch the backend to > SQLLite for example you don't get any errors. > > Funnily enough, I can stop that happening by using the solution given > at:: > > http://www.stereoplex.com/two-voices/django-unit-tests-and-transactions > > Although the comments to that article imply that Django's own unit > test framework should be doing this?
I'm not sure what those comments are referring to, but Django's test framework doesn't currently do anything with transactions. This is mostly because MySQL and SQLite don't support nested transactions, so if Django's test framework used transactions, none of the code being tested would also be able to use transactions. There is a ticket (#8138) that modifies the Django test framework to use transactions, but that change is directed at improving the time required to run tests, not making tests resilient to in-test errors. This is because rolling back a database is a much faster operation than flushing and recreating. The setup/teardown approach suggested by the blog post you reference isn't appropriate for the generic case, but you should certainly consider it for your own projects. If you aren't using transactions in your own code, or you're using a database that supports nested transactions, that approach will certainly work. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
