The above advice is all excellent. I would suggest that you don't need to incorporate this testing into your 'unit testing' for two reasons: 1. you want unit testing to be so painless that developers run it very regularly (ie. multiple times a day); and 2. unit tests should be deterministic. This sort of test, if you can't guarantee to cheat the database time window, will sometimes pass even if the issue is there. The sort of load testing that would turn up all these sorts of errors should really take some time (and perhaps some preparation if you wanted to eg. run multiple clients).

So you might want to add a unit test to confirm that, say, auto-commit is turned off for the relevant db handle (if that's how you implemented it), but proving that there's no time based race condition is a job for stress testing which you should perform regularly, but not as often as unit testing.