#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 mremolt):
Replying to [comment:18 kmtracey]:
> I've looked at this a little more and figured out a few things.
>
> Disconnecting `close_connection` from from `request_finished` solves
this problem, so that tests that use the test Client do not automatically
need to use the old way, and may take advantage of the rollback approach.
In the patch I'll attach the signal is disconnected/reconnected around the
sending of the signal...this is probably overkill. I think it would be OK
to just disconnect `close_connection` from that signal once and be done
with it but I haven't had time to go back and experiment with that since I
tried the first way.
Great, I always wondered why the test client behaved that way and
suspected threading/process problems.
> Second, having the fixture teardown code attempt to detect whether a
commit had been performed by the test code (despite the test case being a
type that supposedly didn't use transactions) and fallback to flush/reload
didn't seem to be working too well. I tried tracking down a few of the
failures caused by these and eventually decided to try a different
approach, which is: if it's a test case that says it doesn't need
transactions to work, monkey patch the transaction commit/rollback and
enter/leave transaction management routines so that even if they are
called by the code being tested, they do nothing, for the duration of the
test.
>
>
> I don't know how the monkey patch idea will be received, but this
approach seems to work better. Doing it this way, none of the existing
Django tescases need to use the old flush/reload approach. That is, the
tests that do actually call commit or rollback (like admin_views, which
call admin views that are wrapped in commit_on_success) don't actually
need those calls to do anything in order for the test to properly test
what it is trying to test. Things work fine when those routines don't do
anything, and the test fixture teardown is able to reliably un-do what the
test has done, leaving things clean for the next test.
What about adding signals to transaction processing? It could simplify the
code here and might be useful at other places. Whenever a transaction is
commited, a signal post_commit is emitted. This signal is catched by the
test case and if it is a case that shouldn't need transactions, it simply
throws an TransactionNotAllowedHere exception "That's evil! Please use the
TestCase that can handle transactions.". That way no monkeypatching is
necessary and it tells the developer what she/he is doing wrong.
Instead of trying to guess if a transaction happened (was a bad idea) or
deactivating transactions transparently (if a test relies on the commit,
the developer will have some nice head scratching), it simply enforces the
developer to use the right TestCase. What do you think?
By the way, during the holidays (when that damned website is online) I can
start contributing to that patch again, if my help is wanted.
--
Ticket URL: <http://code.djangoproject.com/ticket/8138#comment:19>
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
-~----------~----~----~----~------~----~------~--~---
