#8138: Switch django tests to use transactions
----------------------------------------+-----------------------------------
Reporter: mremolt | Owner: nobody
Status: new | Milestone: post-1.0
Component: Testing framework | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
----------------------------------------+-----------------------------------
Comment (by kmtracey):
I actually think it should be relatively easy for developers to know that
what they are testing requires working transaction methods. You need, for
example, to be testing that in a sequence of n updates where some will
succeed but ultimately a failure will be encountered causing the whole set
to be rolled back, to be testing to make sure that some of the initial DB
updates that were made were actually rolled back by the subsequent
failure. This sort of test will not be able to work with the do-nothing
transaction routines, it would have to use !TransactionTestCase to run
successfully, and I think the failure when run under a simple !TestCase
would be pretty obvious.
As for commit, I think it would be relatively hard to write a test that
will notice an expected commit has not been done, since you'd have to
somehow do a query from outside the context of the test case transaction
to be able to tell that what would ordinarily have been committed by the
code under test hasn't actually been committed yet.
I also think it's pretty nice to be able to get the speedup offered by the
rollback test approach even for code under test that calls transaction
routines, when in fact the tests don't need those routines to be
functional in order to correctly test what they are intending to test.
The admin views fall into this category. The edit view, for example, is
wrapped in commit_on_success, which if running on a transaction-supporting
database provides a nice all-or-nothing guarantee for, say, multiple
updates to inine-edited objects. But we don't have any tests for that
guarantee (they would necessarily fail on MySQL/MyISAM). So as far as the
admin_views tests are concerned any commits/rollbacks done by the code
under test aren't critical to the proper functioning of the test. It
would seem a shame to require these tests to take the performance hit of
having to use the flush/load test approach simply because admin provides
the all-or-nothing behavior when run on a transaction-supporting DB.
So it seems the more I think about it the more I like the monkey-patching
approach, personally. (I am perhaps being unduly influenced by being able
to run the full Django test suite on one of my machines now in under 10
minutes where before near an hour was the minimum...and under and hour
even on my very slow old test machines where before a day or overnight run
was required.)
I'll be around over the holidays but won't have much time free since I'll
have family visiting. If you (or anyone) could figure out the PostgreSQL
time issue that would be a good thing to fully understand before moving
forward with this. Also if there's a more elegant way to test for "the DB
rollback works" and what the consequences of it not working are w.r.t.
!DoctTests. Is what's in the patch I attached last night equivalent to
the old approach when run on a non-transaction-supporting DB given that
the fixture loading for unit tests will flush/reload, making it no big
deal that the rollback after a !DocTest run does nothing? The old
approach didn't appear to bracket !DocTests with any sort of DB
flush/reload so maybe thing are OK there, but I didn't pay a whole lot of
attention to the !DocTest bits as I was looking at this since most of the
errors I was hitting had to do with unit tests.
--
Ticket URL: <http://code.djangoproject.com/ticket/8138#comment:20>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
