#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 ericholscher):
It appears that Ellington has a custom test runner for doc tests
(basically the patch from #5624). I missed this earlier (and that explains
why there was no difference between the above patches in my reply before
this).
We are currently doing a flush and then a loaddata on fixtures found in
doctests. We are loading fixtures in the doc tests, and not cleaning them
up (until next time around when a flush occurs it seems.) I believe that a
unit test is being run in between all of these instances, probably rolling
back the transaction at the end (as I understand it, my database knowledge
is lacking), which is allowing the rest of the tests to pass.
The good news is that I now have the entire ellington suite passing with
the above behavior (with 11x speed increase). We had a couple instances of
tests relying on a previous test's data sticking around, and one instance
of a test depending on the pk of it's contents to pass. Fixing those up
allowed me to make all of the test suite pass.
Taking out the flushing threw things through a loop. With the tzcommit
patch, I was getting some collision of slug fields. This was caused by
incomplete fixtures that didn't have a slug, and used to work because
there wasn't another thing of that value being set in that test. These are
now fixed.
I think that it will be possible to get the full suite running on the
patch that does doctest transaction rollbacks. However, since we are
loading fixtures outside of the doctest runner currently, I am getting
some bleed over on tests. I'm assuming this is because the loaddata is
happening before the call to the DoctestRunner. If we put this fixture
loading logic there, inside the transaction, I think all tests would now
pass. I think the fact that we're using fixtures in doctests basically
makes it so that we have to run a custom test runner (unless #5624 gets
accepted, where transactions would almost be necessary around doctests...
This would solve the inconsistency, and give a reason to have rollbacks on
doctests.)
An interesting benchmark; the test suite when I take out the flush took
around 180s to run. (This is almost around a real 30x speed increase, and
3x faster than with the flush.). Unit tests seem to gain even more
performance from transactions because the database was being flushed
before every test (IIRC).
Sorry about the false report before, and let me know if there's anything
else I can do. I'll spend some time tomorrow trying to get our suite
passing without flushing of the DB, probably by moving out fixture loading
inside the transaction in doctests.
--
Ticket URL: <http://code.djangoproject.com/ticket/8138#comment:27>
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
-~----------~----~----~----~------~----~------~--~---
