|There's more than one way to do things|
Testing transactionsby matija (Priest)
|on Jan 24, 2008 at 10:55 UTC||Need Help??|
matija has asked for the
wisdom of the Perl Monks concerning the following question:
I'm writing a Dbix::Class model which I expect will come under a considerable load.
Part of the operations the model will have to perform involves stuff that has to happen in a transaction, and as I am really getting into the write-tests-first way of programming, I want to think up some tests that will verify that the transactions are done right, and that the reverts are handled correctly.
That means that I need to trigger the race conditions "on demand". I've been reading Testing Race Conditions but the responses don't seem to help what I'm trying to test - they would help detect if there are unhandled race conditions, while I want to, first, check that predictable race conditions are properly handled. (And only then go to probabilistic testing if there are any unanticipated race conditions).
Does anybody have ideas on how I could test predictable race conditions (i.e. "what happens if another request comes in just as I come to this point") without having to modify the source I am testing?
Failing that, what would you consider the least intrusive (and the least time consuming in production) modification of the source that would enable such testing?